Skip to content
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

Merged
merged 1 commit into from
Nov 27, 2024

Conversation

mrkajetanp
Copy link
Contributor

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

@mrkajetanp
Copy link
Contributor Author

mrkajetanp commented Nov 7, 2024

It's not fully ready yet, so far I'm looking for some feedback.
The main question is that as is the implementation doesn't check whether CC supports a flag before passing it. I tried using theis_flag_supported(_inner) functions to filter them out but the build script was infinite looping so I thought it could be good to just ask here first.

@NobodyXu

@mrkajetanp mrkajetanp marked this pull request as draft November 7, 2024 17:27
Copy link
Collaborator

@NobodyXu NobodyXu left a 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:

@NobodyXu
Copy link
Collaborator

NobodyXu commented Nov 8, 2024

The main question is that as is the implementation doesn't check whether CC supports a flag before passing it. I tried using theis_flag_supported(_inner) functions to filter them out but the build script was infinite looping so I thought it could be good to just ask here first.

It's because in is_flag_supported we create a new cc::Build object and use it for detecting support.

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 self.flags_supported, which is checked just before compilation without creating a new cc::Build `

https://docs.rs/cc/latest/src/cc/lib.rs.html#1909

@mrkajetanp
Copy link
Contributor Author

To fix this, you could use self.flags_supported, which is checked just before compilation without creating a new cc::Build `

Ah interesting, I can't push to self.flags_supported because that'd require a &mut self, so I could only do that from an explicit builder function, from Build::new() or from compile().

I'm calling add_inherited_rustflags just before the snippet you linked where is_flag_supported_inner is called, should I not be able to just call that function myself directly instead of pushing to the Vec?

@NobodyXu
Copy link
Collaborator

NobodyXu commented Nov 8, 2024

I'm calling add_inherited_rustflags just before the snippet you linked where is_flag_supported_inner is called, should I not be able to just call that function myself directly instead of pushing to the Vec?

Yes in that case you can call is_flag_supported_inner directly

@mrkajetanp
Copy link
Contributor Author

Hmm so I'm calling the new function like this:

        // Add cc flags inherited from matching rustc flags
        if self.inherit_rustflags {
            self.add_inherited_rustflags(&mut cmd, &target)?;
        }

        for flag in self.flags_supported.iter() {
            if self
                .is_flag_supported_inner(flag, &cmd.path, &target)
                .unwrap_or(false)
            {
                cmd.push_cc_arg((**flag).into());
            }
        }

and then inside the function even doing just this makes it infinite loop on creating the Tool for compiler inside is_flag_supported_inner.

        let supported = self
            .is_flag_supported_inner(&cc_flags[0], &cmd.path, &target)
            .unwrap_or(false);

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..

@NobodyXu
Copy link
Collaborator

and then inside the function even doing just this makes it infinite loop on creating the Tool for compiler inside is_flag_supported_inner

Sorry, can you clarify on what function is is_flag_supported_inner being called in that trigger infinite loop?

@mrkajetanp
Copy link
Contributor Author

Sorry, can you clarify on what function is is_flag_supported_inner being called in that trigger infinite loop?

Yep, I'm calling is_flag_supported_inner inside add_inherited_rustflags - that's the second snippet. add_inherited_rustflags is being called inside try_get_compiler - that's the first snippet.

@NobodyXu
Copy link
Collaborator

Sorri I made a mistake

is_flag_suppirted_inner actually creates another cc::Build

So calling it there would trigger infinite loop.

To fix that, you need to disable inherited flags detection in it:

https://docs.rs/cc/latest/src/cc/lib.rs.html#668

@mrkajetanp
Copy link
Contributor Author

Ah indeed you're right, now it makes sense - many thanks! :)

@mrkajetanp mrkajetanp marked this pull request as ready for review November 14, 2024 16:17
@mrkajetanp mrkajetanp requested a review from NobodyXu November 14, 2024 16:17
Copy link
Collaborator

@madsmtm madsmtm left a 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 🎉!

@mrkajetanp mrkajetanp force-pushed the inherit-rustc-flags branch 2 times, most recently from e76efbc to fc181eb Compare November 18, 2024 17:20
Copy link
Collaborator

@madsmtm madsmtm left a 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.

@mrkajetanp
Copy link
Contributor Author

Should be good now I think :)

Copy link
Collaborator

@NobodyXu NobodyXu left a 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

@NobodyXu
Copy link
Collaborator

NobodyXu commented Nov 22, 2024

There's a merge conflict, I'd fine with either a merge or rebase, whatever is convenient to you.

@mrkajetanp mrkajetanp force-pushed the inherit-rustc-flags branch 2 times, most recently from 791ee45 to fff1a82 Compare November 26, 2024 15:19
Copy link
Collaborator

@NobodyXu NobodyXu left a 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.

Copy link
Collaborator

@NobodyXu NobodyXu left a 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.
@mrkajetanp
Copy link
Contributor Author

I squashed the changes into the original commit, don't like unnecessary commit pollution

Copy link
Collaborator

@NobodyXu NobodyXu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@NobodyXu NobodyXu merged commit afb6d60 into rust-lang:main Nov 27, 2024
27 checks passed
@github-actions github-actions bot mentioned this pull request Nov 29, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 23, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 26, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 27, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 27, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 27, 2024
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
poliorcetics pushed a commit to poliorcetics/rust that referenced this pull request Dec 28, 2024
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
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Dec 31, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 15, 2025
…<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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Mechanism for automatically passing flags used by rustc
3 participants