Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
haskell/generic-builder.nix: Fix C lib multiple inclusions #87881
Motivation for this change
Allow the darwin links code to overwrite libs that were already copied, because C dependencies can occur multiple times.
Solves errors like
Allow the darwin links code to overwrite libs that were already copied, because C dependencies can occur multiple times. Solves errors like ln: failed to create symbolic link '/nix/store/higpc9xavwcjjzdipz7m9ly03bh7iy2z-hercules-ci-agent-source-0.7.0/lib/links/libboost_context.dylib': File exists
I think there is also a fix for this in #84985?
However, I don't understand the following things, which is part of the reason why this hasn't been fixed yet:
Thanks @cdepillabout ! I didn't find that PR for some reason. It seems like at some point it solved the problem but it's back to creating a more informative error message instead.
Multiple packages may write links for the same C lib with the same name, causing the issue. I don't think this is a bug. If for example
The darwin linker puts a limit on the total size of the section that references dynamic libraries (correct my wording if needed). Putting them in the links directory means we can reference them with short names via
I've seen a commit by infinisil in the git blame earlier talking about the reasons why. Basically we it's the best we have.
That PR also updates the package set, bumps ghcHEAD and has a lot of code to print a more useful error message. It doesn't actually solve #87880. It only provides a more detailed error message.
The code in question is not executed on any other platform! This is a hack to work around a length limitation of LD_LIBRARY_PATH on Darwin (or, well, it's DYNLIBPATH or whatever, but you know what I mean). Now I remember ... we introduced that hack when MacOS Sierra came out.
I seem to recall that older versions of GHC could not parse the pretty-printed config files properly under certain circumstances, so all the newlines and indentation were removed to work around that issue. It's possible that current versions of GHC don't have that problem any more and that we can remove the un-pretty'fying stage.
There is one other question I had from #84985 (that also applies here): What would happen if a Haskell library depended on two different C libraries that happened to have the same name?
For instance, what if my Haskell library
Reading the code in this PR, it appears that the first
I was thinking this would be a problem, but maybe I'm interpreting the code incorrectly?
In either case, I imagine it is pretty unlikely we run into this error, since different C libraries will probably (hopefully?) have different names.