haskell: remove unused LDFLAGS in generic-builder#43825
haskell: remove unused LDFLAGS in generic-builder#43825matthewbauer wants to merge 1 commit intoNixOS:masterfrom
Conversation
cdf58ae to
9495d52
Compare
|
@GrahamcOfBorg build haskell.packages.ghc821Binary.aeson |
|
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: haskell.packages.ghc821Binary.aeson Partial log (click to expand)
|
|
Failure on x86_64-linux (full log) Attempted: haskell.packages.ghc821Binary.aeson Partial log (click to expand)
|
|
Failure on x86_64-darwin (full log) Attempted: haskell.packages.ghc821Binary.aeson Partial log (click to expand)
|
|
@GrahamcOfBorg build haskellPackages.aeson |
|
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: haskellPacakages.aeson Partial log (click to expand)
|
|
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: haskellPackages.aeson Partial log (click to expand)
|
|
No attempt on x86_64-darwin (full log) The following builds were skipped because they don't evaluate on x86_64-darwin: haskellPacakages.aeson Partial log (click to expand)
|
|
No attempt on x86_64-linux (full log) The following builds were skipped because they don't evaluate on x86_64-linux: haskellPacakages.aeson Partial log (click to expand)
|
|
@GrahamcOfBorg build haskellPackages.aeson |
|
No attempt on aarch64-linux (full log) The following builds were skipped because they don't evaluate on aarch64-linux: haskellPackages.aeson Partial log (click to expand)
|
|
haskell.packages.ghc821Binary.aeson is broken in master apparently. |
|
Failure on x86_64-linux (full log) Attempted: haskellPackages.aeson Partial log (click to expand)
|
|
Failure on x86_64-darwin (full log) Attempted: haskellPackages.aeson Partial log (click to expand)
|
|
Failure on x86_64-linux (full log) Attempted: haskellPackages.aeson Partial log (click to expand)
|
|
Failure on x86_64-darwin (full log) Attempted: haskellPackages.aeson Partial log (click to expand)
|
Ericson2314
left a comment
There was a problem hiding this comment.
Yes I approve of this until we do the mass-rebuild
|
Couldn't some build script in principle compile and run some C code that say, generates numeric tables that get embedded in the source code or whatever? Sounds like #43713 achieves the same thing as this PR except breaking such cases. |
I'm a little bit confused because I think the effect of these two PRs should be the same. I think you're right that in theory a package could have something installed in |
Once haskell has found a package.conf.d file, it no longer needs the traditional -L flag. This commit removes the additional arguments from NIX_LDFLAGS to prevent some systems from hitting the ARG_MAX limit. This should accomplish the same thing as moving the $libdir somewhere else without some of the breakages that would come with /cc @angerman @peti @Ericson2314 - also remove NIX_BUILD_LDFLAGS - protect against accidental removal of added flags in the generic-builder, we want to make sure the NIX_LDFLAGS removal hack only removes the flags that have been added. We make sure that for instance the pattern: -L/nix/store/...-hello-1.0/lib Doesn’t also remove -L/nix/store/...-hello-1.0/lib64 Which must have been added by someone manually (or gotten by some other setup hook).
f4800de to
bd6b945
Compare
|
No, I mean that a Haskell package declares a dependency on some C library, then at build time compiles and runs some standalone C code that requires that library. With this solution the C program wouldn't link. |
|
I don't like this approach as well, because it builds on hacks of hacks. I'd rather see stdenv rebuild where we make binutils setup-hook idempotent. I'm going to give that a go. |
|
Yes I agree, but I think the idea was to have a temporary workaround that isn't a mass rebuild to have Haskell-on-Darwin working sooner. But if you can stand a mass rebuild, I think what I proposed here matthewbauer@110b5e0#r29781349 could do. It's a legit optimization as well to avoid GCC from searching directories that can't possibly contain libraries but might fix Haskell for now. Of course the duplicate LDFLAGS issue needs fixing regardless. |
|
If I understand that commit correctly it goes into the right direction, but we want to set LDFLAGS once and then skip the rest of invocations. |
|
No, what I propose does nothing to the duplicate LDFLAGS problem, it's a totally orthogonal thing. Instead, it skips adding LDFLAGS for derivations that don't contain any 'real' libraries in |
|
That's a good optimization, given that @dezgeg I think we can get through staging quickly if we pick a solution that doesn't require lots of overrides. |
|
Actually this won't work as you have lib prefix in haskell libs: If you limit yourself to depth 1, lots of packages will break since you have |
No, it won't break. If you have some package creating Though now I realize that while this should always work for Linux, I have no idea about other platforms. |
|
Linux/BSD/macOS will likely behave quite similar and I think they adhere to the Windows is a completely different beast though. And also often sticks the |
|
@dezgeg happy to throw 10 hetzner machines to the problem if you code that up :) |
|
I looked around a bit:
So, I guess there still could be a theoretical problem with this, but it would have to be quite unconventional code. I guess it's worth giving a try. I pushed an attempt at: https://github.com/dezgeg/nixpkgs/tree/binutils-lflags |
Well this only removes ldflags it if it has the I definitely agree that this is a hack but it seems much safer than moving |
|
@dezgeg macOS has its own linker |
|
@dezgeg great, 10 Hetzner servers are crunching. I'll also test macos a tiny bit, then we can push to staging. |
|
@dezgeg seems to be all good, can you make a PR against staging-next? |
|
I took the liberty and pushed the commit to staging, |
|
Ok awesome! I will close this for now. Hopefully it is no longer needed! |
|
Can somebody update me: Is a fix for this in |
|
Yes it is definitely in master now. |
Once haskell has found a package.conf.d file, it no longer needs the
traditional -L flag. This commit removes the additional arguments from
NIX_LDFLAGS to prevent some systems from hitting the ARG_MAX limit.
This should accomplish the same thing as moving the $libdir somewhere
else without some of the breakages that would come with.
I don't have a macOS machine right now so cannot verify that this fixes the original issue. I can verify that it correctly removes the extra args from NIX_LDFLAGS though.
/cc @angerman @peti @Ericson2314 @domenkozar @nh2