-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Support cc_toolchain specifying runtime dynamic libraries #16309
Comments
Another situation where this is necessary is if you want to create a hermetic llvm toolchain that supports both macOS and sanitizers. On macOS sanitizer runtimes must be dynamically linked. Thus the macOS LLVM distribution provides prebuilt sanitizer dylibs, e.g.
Neither of these are currently possible to implement with the current toolchain APIs. A hacky workaround suggested to me by @chancila is to (ab)use |
I also have the same challenge. I tried quite some hours now to do the same thing using It seems to me that this parameter would be the canonical way to support this use case, no?
@local_config_cc//:libc++:
It kind of makes sense, but what I do not understand is, why with the Or could the |
The difference may be explained by
Since Instead, I think that you are supposed to pass in file targets rather than bazel/src/main/starlark/builtins_bzl/common/cc/cc_binary.bzl Lines 251 to 254 in 4201c69
Its files are added to the runfiles of every @adrianimboden Could you try if that works? |
ah interesting, I thought that it must be a cc_import/cc_library so that the rpath thing works, but I have not tested the filegroup approach at all. I will try that soon and write back here 👍. Thank you for your fast response. |
I shortly tried it with this target:
and
It does not link against the library.
I think, using |
@adrianimboden I think your problem is that bazel by default links binary in static mode - and it will use Currently there are 2 conditions to make
A side effect of doing Alternatively, you can link the runtime statically, by feeding I think right now the real problem is, it is impossible to enforce at toolchain level, that a library is always dynamically linked and in RPATH, regardless of link mode (which is what John's comment mentions). |
I will try that when I get back to this variant later. Normally, I link statically also. There everything works as expected. I need the dynamic way only for certain cases with sanitizers and such. Thank you very much for your help. For future reference, If I can test anything corresponding to this feature request, I will happily do some testing 😄 |
Ok i have to admit that I did not come very far with So I tried your suggestion anyway and adding
However, even after this change, tools seem to get built with the static runtime all the time. Is there a way to build tools with dynamic dependencies as well?
Edit: |
Also, interestingly Edit: seems to be related to #3592 |
That's because both Starlark |
Can you elaborate? Does the Starlark version behave differently from the native impl? |
Sorry for the false alarm, |
Yeah I think the In my current setup, it is no longer a problem (but I did a lot of changes since then, most with your help here, thanks again). Right now, it looks like this (cc_test which uses genrule which uses cc_binary): $ bazel build --dynamic_mode=off [snip]
$ ldd bazel-bin/some/cc_binary/bin
linux-vdso.so.1 (0x00007ffe411d4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f390ce93000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f390cd44000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f390cd3e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f390cb4c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f390d790000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f390cb40000)
$ ldd bazel-bin/genrule/tool/bin
linux-vdso.so.1 (0x00007ffdd547f000)
libc++.so.2 => /home/thingdust/src/bazel-bin/generators/../_solib___Ccc-compiler-k8/libc++.so.2 (0x00007fe029574000)
libunwind.so.1 => /home/thingdust/src/bazel-bin/generators/../_solib___Ccc-compiler-k8/libunwind.so.1 (0x00007fe029549000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe029526000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe0293d5000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe0293cf000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe0293c5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe0291d3000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe02a473000)
libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007fe0291c9000)
$ ldd bazel-bin/cc_test/bin
linux-vdso.so.1 (0x00007ffe915f8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f71015c2000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7101473000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f710146d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f710127b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7102af5000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f710126f000) It is not really a problem, I was just suprised that the tool builds do not follow the same rules as the other cc_binary rules. After all, It may be better to have a toolchain that works for static and dynamically linked builds :) This I did not have before. |
Hello just want to check what was the resolution here . |
We recently also came across the need to always dynamically link a hermetic libc++ on macOS (together with the hermetic sanitizer libs that requires dynamic linking). Considering what is currently possible with a custom toolchain and #16520 (comment), I think this issue can be resolved by adding a
Compared with the current
This should make the attribute straightforward to implement, while leaving the rest to toolchain authors. Toolchain authors can just write custom rules to check inputs, generate features with link flags, pass the files to this attribute and the loop is closed. @fmeum @oquenchil any thoughts? |
Description of the feature request:
When using a
cc_toolchain
which contains self-contained tools (e.g.clang
+lld
+libstdc++
), and dynamically linking, produced binaries have a runtime dependency on somelibstdc++
being present on the machine.Ideally, we would like our remote execution environment not to have a
libstdc++
present, and would like to specify our hermetically suppliedlibstdc++
from our toolchain as a runtime dependency when a binary is run as an action (e.g. when used in agenrule
).Currently, we're working around this by installing
libstdc++
in our remote execution environment, but we'd really like to get rid of this if possible. I couldn't find any way of configuring acc_toolchain
to set this up.What underlying problem are you trying to solve with this feature?
Being able to run Bazel actions in purely hermetic environments, so that each team using our remote execution infrastructure is forced to bring their own
libstdc++
orlibc++
long in their toolchain, rather than falling back to a shared version.Which operating system are you running Bazel on?
Linux
What is the output of
bazel info release
?release 5.3.1
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD
?No response
Have you found anything relevant by searching the web?
Brief discussion on Slack: https://bazelbuild.slack.com/archives/CA31HN1T3/p1663676883083889
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: