-
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
Make cc_toolchain
to always link (static|dynamic)_runtime_lib
attributes
#16520
Comments
Problem with this as far as I can see is that if we change the behavior of that existing feature we might break existing projects. But I agree that:
is a valid use case and the toolchain should allow this. @brooksmoses, do you have any ideas related this? |
If changing existing feature is undesired, what about adding new fields? Maybe |
Actually, I feel like the cc rules can be refactored for better flexibility and clarity. Ideas: Toolchain rules: some rules can be predefined to ease the creation of new toolchains and modification to existing toolchains.
Default toolchain and other common use cases:
Build rules:
|
Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale. |
This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please post |
Description of the feature request:
Currently, the
(static|dynamic)_runtime_lib
attributes ofcc_toolchain
are ignored when the featurestatic_link_cpp_runtimes
is disabled. Whenstatic_link_cpp_runtimes
is enabled, the toolchain will linkstatic_runtime_lib
statically in static mode, ordynamic_runtime_lib
dynamically in dynamic mode.This FR asks that when
static_link_cpp_runtimes
is disabled,cc_toolchain
will link both thestatic_runtime_lib
anddynamic_runtime_lib
.Ideally and ultimately, it should be something like
cc_import
:cc_toolchain
provides two runtime lib attributes, one for static mode and one for dynamic mode.srcs
attribute ofcc_library
), and properly link by looking at file extensions.What underlying problem are you trying to solve with this feature?
Context: #16309 (comment)
Currently, it is impossible to enforce at toolchain level, that a library is always dynamically (or statically) linked and in RPATH, regardless of link mode:
static_link_cpp_runtimes
is disabled, no library can be injected at toolchain level (unless writing custom features, but dynamic libs will not be in RPATH).static_link_cpp_runtimes
is enabled, you can only inject static libraries in static linking mode (the same for dynamic mode).But 1) some libraries can only be static / dynamic linked (e.g. sanitizer runtimes), or 2) a developer may choose to always dynamic link / static link libc++ / libstdc++. These use cases are not covered at the moment.
Which operating system are you running Bazel on?
Linux, Mac, Windows
What is the output of
bazel info release
?release 6.0.0-pre.20220909.2
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?
#16309
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: