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.

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

gcc: move .dll.a* outputs to $lib #83181

Merged
merged 1 commit into from Apr 11, 2020

Conversation

matthewbauer
Copy link
Member

These are expected to be here for Windows compilation. The change in
e1831eb didn’t move these
correctly (while still patching the search paths).

https://hydra.nixos.org/build/114202790

/cc @lopsided98

Motivation for this change
Things done
  • 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.

These are expected to be here for Windows compilation. The change in
e1831eb didn’t move these
correctly (while still patching the search paths).

https://hydra.nixos.org/build/114202790
@lopsided98
Copy link
Contributor

I don't understand how this used to work. cc_solib used to point to $lib, while it now points to $lib/$targetConfig. The .dll.a files were never located in $lib, so I don't understand why changing cc_solib suddenly causes the toolchain to try to find them in $lib/$targetConfig.

Also, aren't .dll.a files static libraries, in which case they don't really belong in $lib?

@matthewbauer
Copy link
Member Author

I don't understand how this used to work. cc_solib used to point to $lib, while it now points to $lib/$targetConfig. The .dll.a files were never located in $lib, so I don't understand why changing cc_solib suddenly causes the toolchain to try to find them in $lib/$targetConfig.

Before we weren't moving $out/$targetConfig at all right? My assumption is that something referenced in there is getting patched to look for some .dll.a.

Also, aren't .dll.a files static libraries, in which case they don't really belong in $lib?

I think they might be just archives of multiple dll's. It looks like they are referenced in the .la files.

Copy link
Contributor

@lopsided98 lopsided98 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I see, the .la files were patched to reference $lib. I don't know why I assumed the cc_solib change was the cause.

@lopsided98
Copy link
Contributor

This should go to staging, right?

@lovesegfault
Copy link
Member

Yeah, this should go to staging

@FRidh FRidh added this to Needs review in Staging Apr 3, 2020
@matthewbauer matthewbauer changed the base branch from master to staging April 9, 2020 17:24
@matthewbauer matthewbauer merged commit 53752d0 into NixOS:staging Apr 11, 2020
Staging automation moved this from Needs review to Done Apr 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Staging
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

3 participants