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

Allow linker override specifically for build scripts and proc macros #14105

Closed
AldanTanneo opened this issue Jun 19, 2024 · 5 comments
Closed
Labels
A-cross-compiling Area: using --target flag for other platforms A-rustflags Area: rustflags C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request.

Comments

@AldanTanneo
Copy link

AldanTanneo commented Jun 19, 2024

Problem

When cross compiling for a target that has the same architecture as the host, the build scripts and proc macros are compiled with the target linker. However, those builds are not meant to be run on the target!

In my use case, I was building on an x86_64-unknown-linux-gnu host with glibc 2.31, and the target environment was x86_64-unknown-linux-gnu with glibc 2.38, and a specific linker for this target.

The build scripts and proc macros were failing with dynamic linking errors, saying they couldn't find the correct libc version, because they had been linked with the target linker, not the host linker.

Proposed Solution

Allow the user to specify if they want to build the build scripts / proc macros with a different linker or not.

Notes

As a workaround, I used this rustc wrapper script, that will remove the -C linker=... arguments if the crate name is build_script_build, or the crate type is proc-macro

@AldanTanneo AldanTanneo added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Jun 19, 2024
@epage epage added the A-rustflags Area: rustflags label Jun 21, 2024
@epage
Copy link
Contributor

epage commented Jun 21, 2024

Could you provide reproduction steps to remove any chance of misunderstanding in what you are running into?

if I understand correctly, instead of saying cargo build --target <host>, you are doing cargo build and the linker flags are being applied to everything. If so, is there a reason you can't use --target?

Also, if I'm understanding correctly, we have no mechanism to set the linker, so in the end, this is about setting RUSTFLAGS until and unless we expose the linker otherwise (see #12739).

@epage epage added S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request. and removed S-triage Status: This issue is waiting on initial triage. labels Jun 21, 2024
@AldanTanneo
Copy link
Author

AldanTanneo commented Jun 24, 2024

Steps to reproduce:

  • Have a crate with a build script or proc macro somewhere in the dependency tree
  • Start a Debian 11 x86_64 container, and somehow install/copy GCC 12 on it
  • Build the crate with cargo build --target x86_64-unknown-linux-gnu, with GCC 12 as the linker for x86_64-unknown-linux-gnu in .cargo/config.toml
  • Behold: build scripts and proc macros fail to run, as they were linked with GCC 12, which links to glibc >=2.32, and Debian 11 only has glibc 2.31

Admittedly this is a bit of a cursed setup

@epage epage added the A-cross-compiling Area: using --target flag for other platforms label Jun 27, 2024
@epage
Copy link
Contributor

epage commented Jun 27, 2024

So you are using --target , the cross-compiler linker is being used? Is it being used with just cargo build as well?

#4423 is about something similar (RUSTFLAGS for build scripts) but specifically mentions that RUSTFLAGS is only applied to the platform-target builds and not the host-target builds. So how are your host-target builds using GCC 12? I wonder if rustc is using a system linker and somehow GCC 12 is being treated as the system linker. If so, then likely the core of your problem is a system configuration problem, rather than #4423.

if somehow that can't be addressed and can only be solved in Cargo, then this is another version of #4423. Closing in favor of that. If there is a reason for us to keep this open separately, let us know!

@epage epage closed this as not planned Won't fix, can't repro, duplicate, stale Jun 27, 2024
@AldanTanneo
Copy link
Author

AldanTanneo commented Jun 27, 2024

Well my issue boils down to the fact that when target and host have the same triple, the target linker is used for build scripts, which only happens in this case. In a sense, this is the opposite of #4423? As, if I understand correctly, #4423 is about adding flags to build script compilation, and I want to remove some? Unless I did not read the issue far enough.

Someone also made the point in that thread that "cross compiling for the host triple and compiling natively is basically the same thing", which I would argue against...

@AldanTanneo
Copy link
Author

I found an issue on the rust forums with the same problem that might be clearer as to what the issue actually is: https://users.rust-lang.org/t/same-arch-cross-compile-linker-mixup/82337

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cross-compiling Area: using --target flag for other platforms A-rustflags Area: rustflags C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-info Status: Needs more info, such as a reproduction or more background for a feature request.
Projects
None yet
Development

No branches or pull requests

2 participants