-
-
Notifications
You must be signed in to change notification settings - Fork 13k
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
pkgsCross.mingw32.stdenv.cc provides slightly incomplete linking environment: cannot find -lmcfgthread
#156343
Comments
The following workaround seems to be enough to get working pkgsCross.mingw32.stdenv.cc.override ({
extraBuildCommands = ''printf '%s' '-L${pkgsCross.mingw32.windows.mcfgthreads}/lib' >> $out/nix-support/cc-ldflags'';
}) |
A slightly fixed workaround by @trofi that also patches include flags (fixed system-wide Mingw): pkgsCross.mingw32.stdenv.cc.override ({
extraBuildCommands = ''
printf '%s' '-L${pkgsCross.mingw32.windows.mcfgthreads}/lib' >> $out/nix-support/cc-ldflags
printf '%s' '-I${pkgsCross.mingw32.windows.mcfgthreads.dev}/include' >> $out/nix-support/cc-cflags
'';
}) |
I have the same issue when trying to cross-build golang applications, how do you think we should patch the nixpkgs? it seems not easy to override gcc locally. |
Note that this does not happen if you use the compiler (ostensibly the same one) from a stdenv derivation: $ nix build --impure --expr '
let pkgs = (builtins.getFlake "nixpkgs").legacyPackages.${builtins.currentSystem};
in pkgs.pkgsCross.mingw32.stdenv.mkDerivation {
name = "a"; src = ./.;
buildPhase = "$CC -o a a.c";
installPhase = "cp a.exe $out";
}'
$ file -L result
result: PE32 executable (console) Intel 80386, for MS Windows or via a development shell (damn these commands are unpleasant): $ nix develop --impure --expr '
let pkgs = (builtins.getFlake "nixpkgs").legacyPackages.${builtins.currentSystem};
in pkgs.mkShell.override { stdenv = pkgs.pkgsCross.mingw32.stdenv; } { }'
$ $CC -o a a.c
$ file a.exe
a.exe: PE32 executable (console) Intel 80386, for MS Windows
$ which $CC
/nix/store/pl1qhrxnf33s0my900pnnpbp08xhfdyz-i686-w64-mingw32-stage-final-gcc-debug-wrapper-10.3.0/bin/i686-w64-mingw32-gcc
$ ^D even though that same (wrapped) compiler outside such a shell is nonfunctional: $ /nix/store/pl1qhrxnf33s0my900pnnpbp08xhfdyz-i686-w64-mingw32-stage-final-gcc-debug-wrapper-10.3.0/bin/i686-w64-mingw32-gcc -o a a.c
/nix/store/mv3bssklr1g1zwby7bkr62njdh70413s-i686-w64-mingw32-binutils-2.38/bin/i686-w64-mingw32-ld: cannot find -lmcfgthread: No such file or directory
collect2: error: ld returned 1 exit status Are cross compilers even supposed to be usable that way? |
Why not? There might be no other alternative if one wants 5 cross-compilers simultaneously in a single derivation (or more realistically two: 32-bit and 64-bit mingw at the same time). I personally like to install native compiler and a bunch of cross-compilers system-wide so my |
should add whitespace → |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/statically-linked-mingw-binaries/38395/1 |
This comment of mine should probably belong to this issue instead. |
I was trying to install a few cross-compilers to be available in parallel in a single environment as
${target}-gcc
. Looks like mingw one are slightly broken currently. Here is a minimal reproducer:Porblematic attempt
mingw32
:Working
gnu32
attempt:Expected behavior
I expect both cases of compiler to be able to link minimal
int main(){}
example without extra environment settings.Metadata
The text was updated successfully, but these errors were encountered: