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.

Sign up for GitHub

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

Jump to bottom

gcc: copy windows library file to the lib output #84815

Closed
wants to merge 1 commit into from
Closed

gcc: copy windows library file to the lib output #84815

wants to merge 1 commit into from

Conversation

marius851000
Copy link
Contributor

@marius851000 marius851000 commented Apr 9, 2020 •
edited

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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

@marius851000
Copy link
Contributor Author

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)

@FRidh FRidh changed the base branch from master to staging April 27, 2020 18:14
@FRidh FRidh added this to WIP in Staging via automation Apr 27, 2020
@stale
Copy link

stale bot commented Jun 7, 2021

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

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 7, 2021
@Artturin Artturin marked this pull request as draft February 19, 2023 02:15
@marius851000 marius851000 mentioned this pull request Apr 23, 2023
Merged
12 tasks
Staging automation moved this from WIP to Done Apr 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@matthewbauer matthewbauer Awaiting requested review from matthewbauer

Assignees
No one assigned
Labels
2.status: merge conflict 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md 10.rebuild-darwin: 501+ 10.rebuild-darwin: 5001+ 10.rebuild-linux: 501+ 10.rebuild-linux: 5001+ 10.rebuild-linux-stdenv
Projects
Staging
  
Done
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@marius851000 @matthewbauer @ryantm