Add relative RUNPATH entries in haskell_cabal_* targets #1267
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aherrmann
force-pushed
the
cabal-runpath
branch
2 times, most recently
from
134cd1e to
68c3cc4
Compare
Profpatsch
approved these changes
Mar 6, 2020
| py_inline_test( | ||
| name = "stackage_zlib_runpath", | ||
| args = [ | ||
| "$(rootpath :libz_soname)", |
There was a problem hiding this comment.
are solib_names exported as targets?
There was a problem hiding this comment.
It's an output attribute that means that it becomes accessible as a label.
By default Cabal generates `RUNPATH` entries pointing to the sandbox directory. These no longer work outside of that particular sandbox.
Adds a regression test to check that haskell_cabal_library will generate a relative `RUNPATH` entry for the nixpkgs provided zlib.
Addressing #1267 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
haskell_cabal_binary|librarytargets that depended on Bazel managed dynamic C libraries (e.g. the nixpkgs providedlibzfor@stackage//:zlib) were missing relativeRUNPATHentries. Instead, Cabal only generated absoluteRUNPATHentries pointing to the sandbox's execroot, which are invalid outside that sandbox, see #1130. This can cause build failures with Cabal packages that depend transitively on dynamic C libraries, e.g.hie-biosfailed to build in #1262.This PR adds relative
RUNPATHentries in the same fashion as is done for regular Haskell targets.This PR also adds a regression test that checks for the presence of a relative
RUNPATHentry.