-
Notifications
You must be signed in to change notification settings - Fork 481
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
build: Inherit flags from rustc #1279
Conversation
It's not fully ready yet, so far I'm looking for some feedback. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I have some feedback with the code style/lint:
It's because in https://docs.rs/cc/latest/src/cc/lib.rs.html#660 Because the rust flag is turned on by default, it causes infinite looping. To fix this, you could use |
Ah interesting, I can't push to I'm calling |
Yes in that case you can call |
Hmm so I'm calling the new function like this:
and then inside the function even doing just this makes it infinite loop on creating the Tool for
Looking at the code I do not really understand why is_flag_supported_inner doesn't infinite loop on the first snippet already, can you explain what's different about these two calls? Sorry, not very familiar with the codebase.. |
Sorry, can you clarify on what function is |
Yep, I'm calling |
Sorri I made a mistake
So calling it there would trigger infinite loop. To fix that, you need to disable inherited flags detection in it: |
Ah indeed you're right, now it makes sense - many thanks! :) |
306b961
to
a9098fa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for starting on this 🎉!
e76efbc
to
fc181eb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks a lot better to me, thanks for doing the work! Only nits from my side now.
fc181eb
to
1a8e8de
Compare
Should be good now I think :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
I am happy about the direction and general code, just a few questions regarding panic, ergonomic and some simple optimization
There's a merge conflict, I'd fine with either a merge or rebase, whatever is convenient to you. |
791ee45
to
fff1a82
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
This is the last review pass from me, and it mostly contains code suggestions that can be applied easily.
Once resolved I will merge it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should fix the pipeline
Where applicable, detect which RUSTFLAGS were set for rustc and convert them into their corresponding cc flags in order to ensure consistent codegen across Rust and non-Rust modules.
f438b0d
to
559378c
Compare
I squashed the changes into the original commit, don't like unnecessary commit pollution |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
CI: Add LTO support to clang in dist-x86_64-linux After rust-lang/cc-rs#1279, we attempt to pass `-flto=thin` to clang. In `dist-x86_64-linux`, we don't build clang with the `LLVMgold.so` library so this fails. This attempts to resolve this First, pass the binutils plugin include directory to Clang, [which will build the library](https://github.com/llvm/llvm-project/blob/2d6d723a85c2d007b0359c206d66cd2e5a9f00e1/llvm/docs/GoldPlugin.rst#how-to-build-it) Second, this library depends on the *version of libstdc++ that we built* specifically. However, despite both the RPATH and LD_LIBRARY_PATH pointing to `/rustroot/lib`, we incorrectly resolve to the system libstdc++, which doesn't load. ``` # LD_DEBUG=libs,files 2219: file=libstdc++.so.6 [0]; needed by /rustroot/bin/../lib/LLVMgold.so [0] 2219: find library=libstdc++.so.6 [0]; searching 2219: search path=/rustroot/bin/../lib/../lib (RPATH from file /rustroot/bin/../lib/LLVMgold.so) 2219: trying file=/rustroot/bin/../lib/../lib/libstdc++.so.6 2219: search path=/usr/lib64/tls:/usr/lib64 (system search path) 2219: trying file=/usr/lib64/tls/libstdc++.so.6 2219: trying file=/usr/lib64/libstdc++.so.6 ``` Using `LD_PRELOAD` causes it to correctly load the library I think this is probably not the most maintainable way to do this, so opening to see if this is desired and if there's a better way of doing this
CI: Add LTO support to clang in dist-x86_64-linux After rust-lang/cc-rs#1279, we attempt to pass `-flto=thin` to clang. In `dist-x86_64-linux`, we don't build clang with the `LLVMgold.so` library so this fails. This attempts to resolve this First, pass the binutils plugin include directory to Clang, [which will build the library](https://github.com/llvm/llvm-project/blob/2d6d723a85c2d007b0359c206d66cd2e5a9f00e1/llvm/docs/GoldPlugin.rst#how-to-build-it) Second, this library depends on the *version of libstdc++ that we built* specifically. However, despite both the RPATH and LD_LIBRARY_PATH pointing to `/rustroot/lib`, we incorrectly resolve to the system libstdc++, which doesn't load. ``` # LD_DEBUG=libs,files 2219: file=libstdc++.so.6 [0]; needed by /rustroot/bin/../lib/LLVMgold.so [0] 2219: find library=libstdc++.so.6 [0]; searching 2219: search path=/rustroot/bin/../lib/../lib (RPATH from file /rustroot/bin/../lib/LLVMgold.so) 2219: trying file=/rustroot/bin/../lib/../lib/libstdc++.so.6 2219: search path=/usr/lib64/tls:/usr/lib64 (system search path) 2219: trying file=/usr/lib64/tls/libstdc++.so.6 2219: trying file=/usr/lib64/libstdc++.so.6 ``` Using `LD_PRELOAD` causes it to correctly load the library I think this is probably not the most maintainable way to do this, so opening to see if this is desired and if there's a better way of doing this
CI: Add LTO support to clang in dist-x86_64-linux After rust-lang/cc-rs#1279, we attempt to pass `-flto=thin` to clang. In `dist-x86_64-linux`, we don't build clang with the `LLVMgold.so` library so this fails. This attempts to resolve this First, pass the binutils plugin include directory to Clang, [which will build the library](https://github.com/llvm/llvm-project/blob/2d6d723a85c2d007b0359c206d66cd2e5a9f00e1/llvm/docs/GoldPlugin.rst#how-to-build-it) Second, this library depends on the *version of libstdc++ that we built* specifically. However, despite both the RPATH and LD_LIBRARY_PATH pointing to `/rustroot/lib`, we incorrectly resolve to the system libstdc++, which doesn't load. ``` # LD_DEBUG=libs,files 2219: file=libstdc++.so.6 [0]; needed by /rustroot/bin/../lib/LLVMgold.so [0] 2219: find library=libstdc++.so.6 [0]; searching 2219: search path=/rustroot/bin/../lib/../lib (RPATH from file /rustroot/bin/../lib/LLVMgold.so) 2219: trying file=/rustroot/bin/../lib/../lib/libstdc++.so.6 2219: search path=/usr/lib64/tls:/usr/lib64 (system search path) 2219: trying file=/usr/lib64/tls/libstdc++.so.6 2219: trying file=/usr/lib64/libstdc++.so.6 ``` Using `LD_PRELOAD` causes it to correctly load the library I think this is probably not the most maintainable way to do this, so opening to see if this is desired and if there's a better way of doing this
CI: Add LTO support to clang in dist-x86_64-linux After rust-lang/cc-rs#1279, we attempt to pass `-flto=thin` to clang. In `dist-x86_64-linux`, we don't build clang with the `LLVMgold.so` library so this fails. This attempts to resolve this First, pass the binutils plugin include directory to Clang, [which will build the library](https://github.com/llvm/llvm-project/blob/2d6d723a85c2d007b0359c206d66cd2e5a9f00e1/llvm/docs/GoldPlugin.rst#how-to-build-it) Second, this library depends on the *version of libstdc++ that we built* specifically. However, despite both the RPATH and LD_LIBRARY_PATH pointing to `/rustroot/lib`, we incorrectly resolve to the system libstdc++, which doesn't load. ``` # LD_DEBUG=libs,files 2219: file=libstdc++.so.6 [0]; needed by /rustroot/bin/../lib/LLVMgold.so [0] 2219: find library=libstdc++.so.6 [0]; searching 2219: search path=/rustroot/bin/../lib/../lib (RPATH from file /rustroot/bin/../lib/LLVMgold.so) 2219: trying file=/rustroot/bin/../lib/../lib/libstdc++.so.6 2219: search path=/usr/lib64/tls:/usr/lib64 (system search path) 2219: trying file=/usr/lib64/tls/libstdc++.so.6 2219: trying file=/usr/lib64/libstdc++.so.6 ``` Using `LD_PRELOAD` causes it to correctly load the library I think this is probably not the most maintainable way to do this, so opening to see if this is desired and if there's a better way of doing this try-job: dist-i686-linux
CI: Add LTO support to clang in dist-x86_64-linux After rust-lang/cc-rs#1279, we attempt to pass `-flto=thin` to clang. In `dist-x86_64-linux`, we don't build clang with the `LLVMgold.so` library so this fails. This attempts to resolve this First, pass the binutils plugin include directory to Clang, [which will build the library](https://github.com/llvm/llvm-project/blob/2d6d723a85c2d007b0359c206d66cd2e5a9f00e1/llvm/docs/GoldPlugin.rst#how-to-build-it) Second, this library depends on the *version of libstdc++ that we built* specifically. However, despite both the RPATH and LD_LIBRARY_PATH pointing to `/rustroot/lib`, we incorrectly resolve to the system libstdc++, which doesn't load. ``` # LD_DEBUG=libs,files 2219: file=libstdc++.so.6 [0]; needed by /rustroot/bin/../lib/LLVMgold.so [0] 2219: find library=libstdc++.so.6 [0]; searching 2219: search path=/rustroot/bin/../lib/../lib (RPATH from file /rustroot/bin/../lib/LLVMgold.so) 2219: trying file=/rustroot/bin/../lib/../lib/libstdc++.so.6 2219: search path=/usr/lib64/tls:/usr/lib64 (system search path) 2219: trying file=/usr/lib64/tls/libstdc++.so.6 2219: trying file=/usr/lib64/libstdc++.so.6 ``` Using `LD_PRELOAD` causes it to correctly load the library I think this is probably not the most maintainable way to do this, so opening to see if this is desired and if there's a better way of doing this
CI: Add LTO support to clang in dist-x86_64-linux After rust-lang/cc-rs#1279, we attempt to pass `-flto=thin` to clang. In `dist-x86_64-linux`, we don't build clang with the `LLVMgold.so` library so this fails. This attempts to resolve this First, pass the binutils plugin include directory to Clang, [which will build the library](https://github.com/llvm/llvm-project/blob/2d6d723a85c2d007b0359c206d66cd2e5a9f00e1/llvm/docs/GoldPlugin.rst#how-to-build-it) Second, this library depends on the *version of libstdc++ that we built* specifically. However, despite both the RPATH and LD_LIBRARY_PATH pointing to `/rustroot/lib`, we incorrectly resolve to the system libstdc++, which doesn't load. ``` # LD_DEBUG=libs,files 2219: file=libstdc++.so.6 [0]; needed by /rustroot/bin/../lib/LLVMgold.so [0] 2219: find library=libstdc++.so.6 [0]; searching 2219: search path=/rustroot/bin/../lib/../lib (RPATH from file /rustroot/bin/../lib/LLVMgold.so) 2219: trying file=/rustroot/bin/../lib/../lib/libstdc++.so.6 2219: search path=/usr/lib64/tls:/usr/lib64 (system search path) 2219: trying file=/usr/lib64/tls/libstdc++.so.6 2219: trying file=/usr/lib64/libstdc++.so.6 ``` Using `LD_PRELOAD` causes it to correctly load the library I think this is probably not the most maintainable way to do this, so opening to see if this is desired and if there's a better way of doing this
CI: Add LTO support to clang in dist-x86_64-linux After rust-lang/cc-rs#1279, we attempt to pass `-flto=thin` to clang. In `dist-x86_64-linux`, we don't build clang with the `LLVMgold.so` library so this fails. This attempts to resolve this First, pass the binutils plugin include directory to Clang, [which will build the library](https://github.com/llvm/llvm-project/blob/2d6d723a85c2d007b0359c206d66cd2e5a9f00e1/llvm/docs/GoldPlugin.rst#how-to-build-it) Second, this library depends on the *version of libstdc++ that we built* specifically. However, despite both the RPATH and LD_LIBRARY_PATH pointing to `/rustroot/lib`, we incorrectly resolve to the system libstdc++, which doesn't load. ``` # LD_DEBUG=libs,files 2219: file=libstdc++.so.6 [0]; needed by /rustroot/bin/../lib/LLVMgold.so [0] 2219: find library=libstdc++.so.6 [0]; searching 2219: search path=/rustroot/bin/../lib/../lib (RPATH from file /rustroot/bin/../lib/LLVMgold.so) 2219: trying file=/rustroot/bin/../lib/../lib/libstdc++.so.6 2219: search path=/usr/lib64/tls:/usr/lib64 (system search path) 2219: trying file=/usr/lib64/tls/libstdc++.so.6 2219: trying file=/usr/lib64/libstdc++.so.6 ``` Using `LD_PRELOAD` causes it to correctly load the library I think this is probably not the most maintainable way to do this, so opening to see if this is desired and if there's a better way of doing this
…<try> Bump bootstrap cc to 1.2.14 and cmake to 0.1.54 ## Summary Bump bootstrap's `cc` and `cmake` deps: 1. To make it easier to add new/unofficial targets. In particular, `cc` v1.2.4+ allows using env vars to pass target parameters to the `cc` crate. This was previously attempted in rust-lang#134344 but ran into macos-cross-to-iOS problems with `cmake` (and also rust-lang#136440, rust-lang#136720). See also discussions in rust-lang/cc-rs#1317. 2. Fix some flag inheritance warnings. Fixes rust-lang#136338. ## `cc` changelogs between `1.2.0` and `1.2.14` > ## [1.2.14](rust-lang/cc-rs@cc-v1.2.13...cc-v1.2.14) - 2025-02-14 > > ### Other > > - Regenerate target info ([rust-lang#1398](rust-lang/cc-rs#1398)) > - Add support for setting `-gdwarf-{version}` based on RUSTFLAGS ([rust-lang#1395](rust-lang/cc-rs#1395)) > - Add support for alternative network stack io-sock on QNX 7.1 aarch64 and x86_64 ([rust-lang#1312](rust-lang/cc-rs#1312)) > > ## [1.2.13](rust-lang/cc-rs@cc-v1.2.12...cc-v1.2.13) - 2025-02-08 > > ### Other > > - Fix cross-compiling for Apple platforms ([rust-lang#1389](rust-lang/cc-rs#1389)) > > ## [1.2.12](rust-lang/cc-rs@cc-v1.2.11...cc-v1.2.12) - 2025-02-04 > > ### Other > > - Split impl Build ([rust-lang#1382](rust-lang/cc-rs#1382)) > - Don't specify both `-target` and `-mtargetos=` on Apple targets ([rust-lang#1384](rust-lang/cc-rs#1384)) > > ## [1.2.11](rust-lang/cc-rs@cc-v1.2.10...cc-v1.2.11) - 2025-01-31 > > ### Other > > - Fix more flag inheritance ([rust-lang#1380](rust-lang/cc-rs#1380)) > - Include wrapper args. in `stdout` family heuristics to restore classifying `clang --driver-mode=cl` as `Msvc { clang_cl: true }` ([rust-lang#1378](rust-lang/cc-rs#1378)) > - Constrain `-Clto` and `-Cembed-bitcode` flag inheritance to be `clang`-only ([rust-lang#1379](rust-lang/cc-rs#1379)) > - Pass deployment target with `-m*-version-min=` ([rust-lang#1339](rust-lang/cc-rs#1339)) > - Regenerate target info ([rust-lang#1376](rust-lang/cc-rs#1376)) > > ## [1.2.10](rust-lang/cc-rs@cc-v1.2.9...cc-v1.2.10) - 2025-01-17 > > ### Other > > - Fix CC_FORCE_DISABLE=0 evaluating to true ([rust-lang#1371](rust-lang/cc-rs#1371)) > - Regenerate target info ([rust-lang#1369](rust-lang/cc-rs#1369)) > - Make hidden lifetimes explicit. ([rust-lang#1366](rust-lang/cc-rs#1366)) > > ## [1.2.9](rust-lang/cc-rs@cc-v1.2.8...cc-v1.2.9) - 2025-01-12 > > ### Other > > - Don't pass inherited PGO flags to GNU compilers (rust-lang#1363) > - Adjusted zig cc judgment and avoided zigbuild errors([rust-lang#1360](rust-lang/cc-rs#1360)) ([rust-lang#1361](rust-lang/cc-rs#1361)) > - Fix compilation on macOS using clang and fix compilation using zig-cc ([rust-lang#1364](rust-lang/cc-rs#1364)) > > ## [1.2.8](rust-lang/cc-rs@cc-v1.2.7...cc-v1.2.8) - 2025-01-11 > > ### Other > > - Add `is_like_clang_cl()` getter (rust-lang#1357) > - Fix clippy error in lib.rs ([rust-lang#1356](rust-lang/cc-rs#1356)) > - Regenerate target info ([rust-lang#1352](rust-lang/cc-rs#1352)) > - Fix compiler family detection issue with clang-cl on macOS ([rust-lang#1328](rust-lang/cc-rs#1328)) > - Update `windows-bindgen` dependency ([rust-lang#1347](rust-lang/cc-rs#1347)) > - Fix clippy warnings ([rust-lang#1346](rust-lang/cc-rs#1346)) > > ## [1.2.7](rust-lang/cc-rs@cc-v1.2.6...cc-v1.2.7) - 2025-01-03 > > ### Other > > - Regenerate target info ([rust-lang#1342](rust-lang/cc-rs#1342)) > - Document new supported architecture names in windows::find > - Make is_flag_supported_inner take an &Tool ([rust-lang#1337](rust-lang/cc-rs#1337)) > - Fix is_flag_supported on msvc ([rust-lang#1336](rust-lang/cc-rs#1336)) > - Allow using Visual Studio target names in `find_tool` ([rust-lang#1335](rust-lang/cc-rs#1335)) > > ## [1.2.6](rust-lang/cc-rs@cc-v1.2.5...cc-v1.2.6) - 2024-12-27 > > ### Other > > - Don't inherit the `/Oy` flag for 64-bit targets ([rust-lang#1330](rust-lang/cc-rs#1330)) > > ## [1.2.5](rust-lang/cc-rs@cc-v1.2.4...cc-v1.2.5) - 2024-12-19 > > ### Other > > - Check linking when testing if compiler flags are supported ([rust-lang#1322](rust-lang/cc-rs#1322)) > > ## [1.2.4](rust-lang/cc-rs@cc-v1.2.3...cc-v1.2.4) - 2024-12-13 > > ### Other > > - Add support for C/C++ compiler for Neutrino QNX: `qcc` ([rust-lang#1319](rust-lang/cc-rs#1319)) > - use -maix64 instead of -m64 ([rust-lang#1307](rust-lang/cc-rs#1307)) > > ## [1.2.3](rust-lang/cc-rs@cc-v1.2.2...cc-v1.2.3) - 2024-12-06 > > ### Other > > - Improve detection of environment when compiling from msbuild or msvc ([rust-lang#1310](rust-lang/cc-rs#1310)) > - Better error message when failing on unknown targets ([rust-lang#1313](rust-lang/cc-rs#1313)) > - Optimize RustcCodegenFlags ([rust-lang#1305](rust-lang/cc-rs#1305)) > > ## [1.2.2](rust-lang/cc-rs@cc-v1.2.1...cc-v1.2.2) - 2024-11-29 > > ### Other > > - Inherit flags from rustc ([rust-lang#1279](rust-lang/cc-rs#1279)) > - Add support for using sccache wrapper with cuda/nvcc ([rust-lang#1304](rust-lang/cc-rs#1304)) > - Fix msvc stdout not shown on error ([rust-lang#1303](rust-lang/cc-rs#1303)) > - Regenerate target info ([rust-lang#1301](rust-lang/cc-rs#1301)) > - Fix compilation of C++ code for armv7-unknown-linux-gnueabihf ([rust-lang#1298](rust-lang/cc-rs#1298)) > - Fetch target info from Cargo even if `Build::target` is manually set ([rust-lang#1299](rust-lang/cc-rs#1299)) > - Fix two files with different extensions having the same object name ([rust-lang#1295](rust-lang/cc-rs#1295)) > - Allow disabling cc's ability to compile via env var CC_FORCE_DISABLE ([rust-lang#1292](rust-lang/cc-rs#1292)) > - Regenerate target info ([rust-lang#1293](rust-lang/cc-rs#1293)) > > ## [1.2.1](rust-lang/cc-rs@cc-v1.2.0...cc-v1.2.1) - 2024-11-14 > > ### Other > > - When invoking `cl -?`, set stdin to null ([rust-lang#1288](rust-lang/cc-rs#1288)) ## `cmake` changelogs `0.1.51` to `0.1.54` > ## [0.1.54](rust-lang/cmake-rs@v0.1.53...v0.1.54) - 2025-02-10 > > ### Other > > - Remove workaround for broken `cc-rs` versions ([rust-lang#235](rust-lang/cmake-rs#235)) > - Be more precise in the description of `register_dep` ([rust-lang#238](rust-lang/cmake-rs#238)) > > ## [0.1.53](rust-lang/cmake-rs@v0.1.52...v0.1.53) - 2025-01-27 > > ### Other > > - Disable broken Make jobserver support on OSX to fix parallel builds ([rust-lang#229](rust-lang/cmake-rs#229)) > > ## [0.1.52](rust-lang/cmake-rs@v0.1.51...v0.1.52) - 2024-11-25 > > ### Other > > - Expose cc-rs no_default_flags for hassle-free cross-compilation ([rust-lang#225](rust-lang/cmake-rs#225)) > - Add a `success` job to CI > - Change `--build` to use an absolute path > - Merge pull request [rust-lang#195](rust-lang/cmake-rs#195) from meowtec/feat/improve-fail-hint > - Improve hint for cmake not installed in Linux (code 127) > > ## [0.1.51](rust-lang/cmake-rs@v0.1.50...v0.1.51) - 2024-08-15 > > ### Added > > - Add JOM generator support ([rust-lang#183](rust-lang/cmake-rs#183)) > - Improve visionOS support ([rust-lang#209](rust-lang/cmake-rs#209)) > - Use `Generic` for bare-metal systems ([rust-lang#187](rust-lang/cmake-rs#187)) > > ### Fixed > > - Fix cross compilation on android armv7 and x86 ([rust-lang#186](rust-lang/cmake-rs#186)) try-job: dist-apple-various
Where applicable, detect which RUSTFLAGS were set for rustc and convert them into their corresponding cc flags in order to ensure consistent codegen across Rust and non-Rust modules.
Resolves #1254