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

--enable-executable-dynamic not working on packages containing both lib and executables, makes installation problematic #1568

Closed
magthe opened this issue Nov 3, 2013 · 4 comments · Fixed by #2255

Comments

@magthe
Copy link

magthe commented Nov 3, 2013

RPATH for executables is set to include the build location for the library and not the install location for the library. This results in the situation described in detail in this mail.

This makes it rather impossible to install this type of packages when linking dynamically.

@peti
Copy link
Collaborator

peti commented Nov 7, 2013

We use http://nixos.org/patchelf.html to work around this kind of problem in NixOS. It's not pretty, but it works until there's a better solution.

@jessicah
Copy link
Contributor

jessicah commented Nov 4, 2014

I'm facing the same issue on Haiku (ran into the example of pandoc in the linked email thread actually!). We'll be looking into the issue ourselves, so hopefully will have a PR to send your way soon enough...

@jessicah
Copy link
Contributor

I tried looking into this issue, but my experience with Haskell quickly become severely inept!

However, would it suffice as a solution for an invocation of cabal install pandoc (as an example) to split the process into two individual runs?

E.g. run the configure/build/install phase for the libraries; then repeat again for the executable?

During the phase for the executable, cabal would then use the installed library rather than the inplace library.

christiaanb added a commit to christiaanb/cabal that referenced this issue Dec 4, 2014
Before, RPATH handling was left to GHC. But this causes problems
when a package contains both a Library section and an Executable
section which depends on the library, and the executable is
dynamically linked. See e.g. haskell#1568
christiaanb added a commit to christiaanb/cabal that referenced this issue Dec 12, 2014
Before, RPATH handling was left to GHC. But this causes problems
when a package contains both a Library section and an Executable
section which depends on the library, and the executable is
dynamically linked. See e.g. haskell#1568
@jessicah
Copy link
Contributor

Is there some magic incantation I need to pass to Cabal to make this work?

I've just downloaded pandoc sources from Hackage, and run:

~> cd pandoc-1.12.4.2
~/pandoc-1.12.4.2> cabal install --force-reinstalls
~/pandoc-1.12.4.2> readelf -a /boot/system/non-packaged/bin/pandoc | more
...
  0x00000001 (NEEDED) Shared library: [libHSpandoc-1.12.4.2-ghc7.8.3.so]
...
 0x0000000f (RPATH)  Library rpath: [/Data/pandoc-1.12.4.2/dist/build:/boot/system/non-packaged/lib:...]

And version of cabal:

~> cabal --version
cabal-install version 1.22.0.0
using version 1.22.0.0 of the Cabal library

I've just tried with cabal install --force-reinstalls --enable-relocatable but unfortunately that fails due to an OS check =/

Once OS support is added, do I need to change the global configuration to use relocatable builds, or can I get the RPATH handling for free without enabling relocatable builds?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants