-
Notifications
You must be signed in to change notification settings - Fork 460
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
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