gcc: copy windows library file to the lib output

[marius851000]

Motivation for this change

I think interesing to ability of nixos to crosscompile for windows. I tried to do this for gnash, where an old version exist for windows. However, there was an error compiling gettext. This solver the issue, allowing gettext to compile for windows.

Things done

copy *.dll and *.a file to the lib output of gcc. I'm not sure if I should copy *.a file, however.

Note: I just tested compilation of pkgsCross.mingwW64.gettext, and every thing that depend on it. It should impact other platform version of the gcc library. Further testing show this also allow pkgsCross.mingwW64.gmp to compile.

I'm a bit worried to this do a full rebuild of gcc for every user, but I can't add a conditional instruction that do this for windows only without changing the hash of the builder.

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[matthewbauer]

Thanks for working on this! This is pretty close to #83181, although I never waited long enough for my PR to build, so it's good to hear this works.

Moving all .a files might end up moving some things we don't expect. I'm not sure if it's an actual problem though.

[marius851000]

Good (once again, should have first searched for existing solution). The file not copied finish in the default derivation. For this windows version, that means there is a file ( khn4v05sy8783wjbqq8z32k7fz5s55sw-x86_64-w64-mingw32-stage-final-gcc-debug-9.2.0/x86_64-w64-mingw32/lib/libstdc++.dll.a-gdb.py ) that isn't copied. Maybe it should be moved too, but I don't see what a python script do here (maybe an helper for debugging).

On the native (linux-x86_64) version of gcc, there is effectivelly .a file in the bin output in the lib folder (as well as .spec and .o file).
Those ar archive seem to contain object file as well as debug information for the library. Is there any specific reason for those being in the bin derivation ?

[matthewbauer]

That may be intentionally there. I’m not actually sure but probably want to leave it as is just in case.

[marius851000]

Ok, so the .o file contained in the .a are for static linking, and so shouldn't go in here. I have however another maybe related error (but that happen in both this and the latest nixpkgs): A lot of linker error with static library (for example, freetype for mingwW64 complain a lot about missing png* function (depend on libpng). I have the interesing message (many package have similar error)

*** Warning: This system cannot link to static lib archive /nix/store/awgrwgr5sgladyakadl1mlkhwhghp0is-libpng-apng-1.6.37-x86_64-w64-mingw32/lib/libpng16.la.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

From libtool.
However it doesn't seem to complain about zlib, that have a .dll.a file (while the libpng16.la contain mention for libpng16.a). Maybe you know how to solve this (or not)

[stale]

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