-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the default solib dir to the rpath for shared libs with transitions. #14011
Conversation
When an executable has dynamically-linked dependencies that have transitions, shared libraries are looked up under rpaths like this: $ORIGIN/(../)*_solib_k8/../../../k8-fastbuild-ST-[0-9a-f]+/bin/_solib_k8 Unless running under the execroot, the transitioned solib directory may not be available at all; the right files will be present under the default solib directory, so it should be on the rpath. Adding the default solib directory to the rpath may cause the wrong version of a shared library to be loaded, e.g. if it has been compiled in the default configuration. To prevent this, we also add the transition mnemonic to the mangled name of the library (adding the default solib last to the rpath won't really help, because it can legitimately be added first).
Hey @oquenchil, do you think this might make it on time for Bazel 5 (#14013)? This is mostly the same patch as before, with the change you asked me to make. Thanks! |
Sorry, I need to carefully review this change and see that it doesn't affect anything negatively internally. I haven't had time to do so yet. |
Thanks for being so patient. This looks good and internally the tests pass with minor modifications that I can take care of. But I'm still trying to wrap my head around all this, so please bear with me.
When you say the execroot, you mean the repository root where you run As I understand it, if you move the location of the executable, ORIGIN changes, but the code still works regardless of where you move the binary, doesn't it? So where is the solibdir when you have That's for the default solibdir. Why doesn't the same thing apply for the transitioned solibdir, i.e.: ../_solib_k8/../../../k8-fastbuild-ST-? If you placed the default solibdir there manually, why not this one as well? If the default solibdir was in runfiles and you copied runfiles, how come that the transitioned solibdir isn't in runfiles too? I realize that it should be the other way around where I'm answering the questions but since you have a better understanding of what the actual problem is I thought you could help. Thanks! |
I should be the one to thank you – I'm sorry I've been nagging you about it, and I really appreciate your taking the time to work on this. I'm happy to help any way I can; if you'd like to have a chat over this, I can try and demo what I'm seeing – please just let me know. There seems to be a difference between the layout in local execution (i.e. where Indeed, the trigger for filing the original issue was a cc_test that always failed in remote execution, but always passed locally. I found that it depended only on transitioned libraries – so the default solib dir wasn't on the rpath, whereas that's where all the SOs were in RE. I put together a gist that I hope demonstrates this: https://gist.github.com/quval/5077b2edc902e9dc0bcad2311a245ffa. |
Alright, understood, thank you very much for the great contribution. I will merge now. @ulfjack Have you never bumped into this issue? |
PR bazelbuild#14011 took care of cc_libraries, this fixes the same issue for cc_imports. Work towards bazelbuild#13819.
PR bazelbuild#14011 took care of cc_libraries, this fixes the same issue for cc_imports. Work towards bazelbuild#13819.
PR bazelbuild#14011 took care of cc_libraries. This fixes the same issue for cc_imports. Work towards bazelbuild#13819. Closes bazelbuild#14272. PiperOrigin-RevId: 427137675 (cherry picked from commit 8734ccf)
When an executable has dynamically-linked dependencies that have transitions, shared libraries are looked up under rpaths like this:
Unless running under the execroot, the transitioned solib directory may not be available at all; the right files will be present under the default solib directory, so it should be on the rpath.
Adding the default solib directory to the rpath may cause the wrong version of a shared library to be loaded, e.g. if it has been compiled in the default configuration. To prevent this, we also add the transition mnemonic to the mangled name of the library (adding the default solib last to the rpath won't really help, because it can legitimately be added first).
#13819