Describe the bug
I am encountering an issue when cross-compiling with a Windows library installed, libpthread in this example. GCC is incorrectly picking up the Windows library instead of the system one.
I came across this in the context of a Rust project with a build.rs file. First, the build file has to be compiled for and executed on the host platform with GCC. Afterward, the rest of the project can be compiled for the target with MinGW.
NIX_LDFLAGS contains the Windows library when it's installed, which causes GCC to error because it doesn't obviously understand the format. If I manually remove it from the environment, then MinGW doesn't know where to pick up the library and the build fails.
Steps To Reproduce
Steps to reproduce the behavior:
- Clone https://github.com/kognise/crosscomp-mcve
- Run
nix-shell --pure
- Run
cargo clean && cargo build --target x86_64-pc-windows-gnu
Expected behavior
I'm relatively new to Nix, so I honestly don't know what the right solution to this is.
The expected behavior from a developer's perspective is simply for GCC to find the Linux libpthread and for MinGW to find the Windows version so that everything can compile nicely.
Screenshots


Additional context
I would just like to mention that this isn't a problem with Rust exclusively, or the overlay I'm using. This is just the simplest way I've been able to reproduce it, and how I came across the issue during real-world development.
Notify maintainers
Not sure who I should specifically ping for this, so apologies if I incorrectly mentioned you.
@matthewbauer (from MinGW derivation history)
@madjar @cstrahan @globin @Havvy (from rustc maintainers, probably didn't need to ping all of you so sorry)
Metadata
- system:
"x86_64-linux"
- host os:
Linux 5.10.67, NixOS, 21.05.3367.fd8a7fd07da (Okapi)
- multi-user?:
yes
- sandbox:
yes
- version:
nix-env (Nix) 2.3.15
- channels(root):
"nixos-21.05.3367.fd8a7fd07da"
- channels(kognise):
"nixos-21.05-21.05.3367.fd8a7fd07da"
- nixpkgs:
/nix/var/nix/profiles/per-user/root/channels/nixos
Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:
Describe the bug
I am encountering an issue when cross-compiling with a Windows library installed,
libpthreadin this example. GCC is incorrectly picking up the Windows library instead of the system one.I came across this in the context of a Rust project with a
build.rsfile. First, the build file has to be compiled for and executed on the host platform with GCC. Afterward, the rest of the project can be compiled for the target with MinGW.NIX_LDFLAGScontains the Windows library when it's installed, which causes GCC to error because it doesn't obviously understand the format. If I manually remove it from the environment, then MinGW doesn't know where to pick up the library and the build fails.Steps To Reproduce
Steps to reproduce the behavior:
nix-shell --purecargo clean && cargo build --target x86_64-pc-windows-gnuExpected behavior
I'm relatively new to Nix, so I honestly don't know what the right solution to this is.
The expected behavior from a developer's perspective is simply for GCC to find the Linux
libpthreadand for MinGW to find the Windows version so that everything can compile nicely.Screenshots
Additional context
I would just like to mention that this isn't a problem with Rust exclusively, or the overlay I'm using. This is just the simplest way I've been able to reproduce it, and how I came across the issue during real-world development.
Notify maintainers
Not sure who I should specifically ping for this, so apologies if I incorrectly mentioned you.
@matthewbauer (from MinGW derivation history)
@madjar @cstrahan @globin @Havvy (from rustc maintainers, probably didn't need to ping all of you so sorry)
Metadata
"x86_64-linux"Linux 5.10.67, NixOS, 21.05.3367.fd8a7fd07da (Okapi)yesyesnix-env (Nix) 2.3.15"nixos-21.05.3367.fd8a7fd07da""nixos-21.05-21.05.3367.fd8a7fd07da"/nix/var/nix/profiles/per-user/root/channels/nixosMaintainer information: