Have rustc report --disable-elf-tls option #27057
Labels
A-frontend
Area: Compiler frontend (errors, parsing and HIR)
Comments
|
I would personally prefer to avoid this for now and take the route of #26581, but I can see where this would be a perhaps useful addition to |
steveklabnik
added
the
A-frontend
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Dec 19, 2015
This transitions the standard library's `thread_local!` macro to use the freshly-added and gated `#[cfg(target_thread_local)]` attribute. This greatly simplifies the `#[cfg]` logic in play here, but requires that the standard library expose both the OS and ELF TLS implementation modules as unstable implementation details. The implementation details were shuffled around a bit but end up generally compiling to the same thing. Closes rust-lang#26581 (this supersedes the need for the option) Closes rust-lang#27057 (this also starts ignoring the option)
jroesch
pushed a commit
to jroesch/rust
that referenced
this issue
Jan 4, 2016
This transitions the standard library's `thread_local!` macro to use the freshly-added and gated `#[cfg(target_thread_local)]` attribute. This greatly simplifies the `#[cfg]` logic in play here, but requires that the standard library expose both the OS and ELF TLS implementation modules as unstable implementation details. The implementation details were shuffled around a bit but end up generally compiling to the same thing. Closes rust-lang#26581 (this supersedes the need for the option) Closes rust-lang#27057 (this also starts ignoring the option)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Per https://bugzilla.mozilla.org/show_bug.cgi?id=1181441#c4 we have the
--disable-elf-tlsoption to support MacOS X 10.6. This requires a custom build, and therefore users need a way to detect whether a given build has that customization.For Firefox I wrote a configure feature test. There's a school of autotools coding which asserts this is best because it's more robust to test the actual thing you need (linking rust to C++ targeting 10.6). However it is slow and wordy, and we'd like to be able to just ask rustc how it was built.
Two ideas:
--print cfgswitch which reports the various #[cfg] values on the command line. Driver scripts could call this and parse the output. This is a general mechanism which might be useful for other features.--disable-elf-tlsoption could append a build specifier like+notlsto the semver, and driver scripts could look for that in the output ofrustc --version. Could be a quick fix.NB we'd like to remove the need for
--disable-elf-tlsentirely (#26581) at which point we could require a minimum rustc version to assert this, but until that time I think it's helpful to address this.cc @alexcrichton
The text was updated successfully, but these errors were encountered: