-
Notifications
You must be signed in to change notification settings - Fork 697
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
Don't use installedPkgs for internal library library dirs. #4033
Conversation
@ezyang, thanks for your PR! By analyzing the history of the files in this pull request, we identified @christiaanb, @dcoutts and @23Skidoo to be potential reviewers. |
In 1.24, installedPkgs contained only references to the external package database, not any internal libraries. In particular, when we built a dynamically linked executable, installedPkgs did NOT have a reference to the internal library; instead, depLibraryPaths has a special case (hasInternalDeps) to add the final libdir to the RPATH. In HEAD, after 0d15ede, we started adding internal libraries (with the INPLACE registrations) to installedPkgs to fix haskell#2971. But depLibraryPaths was not updated, which means that the inplace registrations got picked up and added to the RPATH, resulting in bad temporary directories showing up in RPATHs. In this commit, we just filter out internal entries from installedPkgs and compute the library dirs for them from scratch (this code already existed, so no loss!) Fixes haskell#4025. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
CC @trofi |
Last call for CRs otherwise I'm merging this sucker. |
Looks reasonable to me. |
Tried to apply it on top of ghc-HEAD and it's Cabal submodule and it worked! Thank you! I have another question though (see below) :)
Cabal is supposed to install dyn libs to the same shared location.
Worth a separate bug report? |
Yeah, that also sounds like a bug. |
Filed #4046 |
In 1.24, installedPkgs contained only references to the external package
database, not any internal libraries. In particular, when we built a
dynamically linked executable, installedPkgs did NOT have a reference to
the internal library; instead, depLibraryPaths has a special case
(hasInternalDeps) to add the final libdir to the RPATH.
In HEAD, after 0d15ede, we started adding internal libraries (with the
INPLACE registrations) to installedPkgs to fix #2971. But depLibraryPaths
was not updated, which means that the inplace registrations got picked
up and added to the RPATH, resulting in bad temporary directories
showing up in RPATHs.
In this commit, we just filter out internal entries from installedPkgs
and compute the library dirs for them from scratch (this code already
existed, so no loss!)
Fixes #4025.
Signed-off-by: Edward Z. Yang ezyang@cs.stanford.edu