Cross compiling for mingw doesn't find gcc DLLs

[expipiplus1]

Issue description

Cross compiling for mingw doesn't find gcc DLLs

Steps to reproduce

Check out nixpkgs 0e7c9b3

Build this derivation:

(import <nixpkgs> {
  crossSystem = {
    config = "x86_64-pc-mingw32";
    libc = "msvcrt";
  };
}).hello

Observe that no DLL links are created.

post-installation fixup
DLLPATH='/nix/store/ifb3aj50q60c2scnh8f882a8r961zn26-hello-2.10-x86_64-pc-mingw32/bin:/nix/store/y5rlyv6nz8134s687d95ysc2gakwx7am-patchelf-0.9/bin:/nix/store/rf7pnq8qk9bkjpl4s2pm5dm2pk4yqhrc-paxctl-0.9/bin:/nix/store/00yzxnmmn02hfcz5zgmlij3wrnn0c92y-x86_64-pc-mingw32-gcc-cross-wrapper-7.3.0-x86_64-pc-mingw32-stage-final/bin:/nix/store/iwhhg7qpvlsgznn8ywyd0g9698sl385l-gcc-7.3.0-x86_64-pc-mingw32-stage-final/bin:/nix/store/cb3slv3szhp46xkrczqw7mscy5mnk64l-coreutils-8.29/bin:/nix/store/6bfyi9qdigj0mvprancyvg5y4l3rcm6s-x86_64-pc-mingw32-x86_64-pc-mingw32-binutils-wrapper-2.28.1/bin:/nix/store/jyl00pcg40mzfvrk29dzzc4z8mgi4mkh-x86_64-pc-mingw32-binutils-2.28.1/bin:/nix/store/cb3slv3szhp46xkrczqw7mscy5mnk64l-coreutils-8.29/bin:/nix/store/cb3slv3szhp46xkrczqw7mscy5mnk64l-coreutils-8.29/bin:/nix/store/364b5gkvgrm87bh1scxm5h8shp975n0r-findutils-4.6.0/bin:/nix/store/cg3yhpr5hfr00y0aah23pgxiijpzl6nz-diffutils-3.6/bin:/nix/store/navldm477k3ar6cy0zlw9rk43i459g69-gnused-4.4/bin:/nix/store/s63b2myh6rxfl4aqwi9yxd6rq66djk33-gnugrep-3.1/bin:/nix/store/j79xs2j519bmvq0gihz8ff4nw5aj3vlh-gawk-4.2.0/bin:/nix/store/2p00w952ljb1172nsf3jm7nsjgsw5qpw-gnutar-1.30/bin:/nix/store/d7895h1an2pgcd6a3vx3yb5fbg786lci-gzip-1.9/bin:/nix/store/qqv6r9vkpb44rw5d8wyfpx64rgqzlvdm-bzip2-1.0.6.0.1-bin/bin:/nix/store/lhp5rw0dagi5mgqwr9i3x41240ba4ypz-gnumake-4.2.1/bin:/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin:/nix/store/gd1mp76qr4zpbw3lccivhvi30b025x51-patch-2.7.6/bin:/nix/store/aakgkcvw6j54zg38zrn1w00sgxx0zj8b-xz-5.2.3-bin/bin'
Created 0 DLL link(s) in /nix/store/ifb3aj50q60c2scnh8f882a8r961zn26-hello-2.10-x86_64-pc-mingw32/bin

Observe that the generated hello.exe doesn't run on windows as libssp-0.dll is missing.

libssp-0.dll is present in the x86_64-pc-mingw32/lib/ directory of gcc-7.3.0-x86_64-pc-mingw32-stage-final, however only the bin directories are searched (see pkgs/build-support/setup-hooks/win-dll-link.sh``:19)

This could be fixed by either changing win-dll-link to search in these directories, or by linking these DLLs into the bin/ directory of the cross compiler.

Annoyingly this will cause the closure of any cross compiled derivations to include GCC. Splitting the cross compiler and its libraries into separate derivations may solve this (I think this happens for native packages)

CC @Ericson2314

[expipiplus1]

Seems to happen on master 4366659 too

[Ericson2314]

CC @dtzWill who knows static linking in nixpkgs things and @angerman who is working on Windows haskell cross compilation.

[Ericson2314]

@expipiplus1 pkgs/build-support/setup-hooks/win-dll-link.sh is not something I was aware of. Just searching bin/ seems blatantly wrong so I'll change it.

[Ericson2314]

CC @vcunat who wrote the original scripts. I don't really know what the windows/cygwin/mingw convention is anyways.

[dtzWill]

Related: #36947
Where even on native gcc libs are expected to be from glibc.lib which we copy from bootstrap tarball for some reason.

IIRC such inclusion masked problems in cross where gcc wouldn't search the right locations but kinda worked in native since glibc had (old, wrong) copies available. Not sure if that's what you're seeing, I'll add details later if I can find my notes about it :).

[angerman]

libssp-0.dll, is the stack-protecting logic. I'd suggest to just set hardeningDisable = [ "stackprotector" ];. See also: nix-hs-hello-windows/config.nix#L9-L22.

In general, I think for cross compilation we really want fully static, and stay out of the dynamic mess. For windows, in general you likely want to fetch the referenced dlls and ship them alongside the binary (copy).

[Ericson2314]

Ok I talked a bit on #msys and making the script traverse more directories seems like the right approach. Libraries still be "installed" in lib/, but be put in bin/ for each use.

[Ericson2314]

Ah! and crucially, we should put symlinks of the transitive DLLs of each DLL in lib/, too! That's what's really missing.

[vcunat]

Well, I don't know any conventions; I'm really dumb around Win-specific dev stuff. This was just a quick hack I made up a couple years ago, but I haven't really used mingw (or cygwin) since that time...

[Ericson2314]

#38632 is a draft. It's shellchecked, but needs testing.

[ghost]

on older nixos (before cross-compilation changes in the last two releases or so)
compiling hello.exe worked fine.
the idea was that all dependencies (dll files) were recursively copied to the same bin directory
as the executable. this is because on windows, current directory is searched by default
and it does not need any special configuration to find the dll files.
i do not think that moving the dependencies to a different directory is a good idea.

[matthewbauer]

This appears to be fixed? At least the example work fine for me.

[Ericson2314]

That would be odd? Without #38632 and more I don't see how we would be reliably putting the right DLLs in the bin directory.

[matthewbauer]

I think it might have been fixed by just disabling ssp at some point. I guess that’s not really a long term fix though.

Honestly though, could we just always build windows statically? The windows linker doesn’t really fit well with the nix store path model anyway.

[Ericson2314]

For release-cross purposes, sure. But I don't want to give up on this irrevocably as DLLs are so idiomatic there. IIRC my script, once cc-wrapper behaves, makes it work pretty well as all the propagation is delayed to just exes, so we don't bloat library derivations.

[tex]

On current master, the original example works. wine is able to run generated exe without any issue.

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[Radvendii]

The hello package seems to work, but it's still the case that DLLs are not forwarded. I'm trying to cross-compile something else, and no DLLs are showing up. Additionally, there isn't any lib/ folder in any of the cross-compiled libraries' derivations. The DLLs they build are being put in the bin/ folder, but not forwarded to any packages that depend on them.

[ghost]

Taeer Bar-Yam <notifications@github.com> writes:

The hello package seems to work, but it's still the case that DLLs are not forwarded. I'm trying to cross-compile something else, and no DLLs are showing up. Additionally, there isn't any `lib/` folder in any of the cross-compiled libraries' derivations. The DLLs they build are being put in the `bin/` folder, but not forwarded to any packages that depend on them.

this used to work dlls were recursively copied to bin directory from all dependencies (vcunat developed that for me a few years ago) iirc somebody changed that for some reason; there is a discussion on this topic which i cant find quickly maybe git log could show something interesting which needs reverting (probably search *.sh files with bat in them or something like that)

[Radvendii]

Ah, so the file in question is the one referenced above, win-dll-link.sh. It still exists and is still executed, but does not do anything. I will try to figure out why and how to fix it. It looks like that work was already started, then abandoned because nobody had time. I have plenty of time :P

[stale]

I marked this as stale due to inactivity. → More info