[arch-haskell] Dynamic executables and RPATH

Fabien Dubosson fabien.dubosson at gmail.com
Fri Nov 1 12:04:44 UTC 2013


On the road of dynamic linking for Haskell executables, Magnus has pushed a
commit [1] on `cblrepo` yesterday. This commit adds the cabal flag
`--enable-executable-dynamic`. It follows a previous discussion on this
mailing list [2] and solves some of the cited problems. I tried to build
`pandoc` dynamically this morning, and there is only one issue left (unless
I do something wrong?).

For dynamic linking, Cabal/GHC embed an RPATH into the executable:

    $ readelf --dynamic /usr/bin/pandoc
    0x000000000000000f (RPATH)              Library rpath:

This is working to find all libraries except one: `
libHSpandoc-1.12.1-ghc7.6.3.so`. The reason is the following: At compile
time, cabal first builds the pandoc library, then the pandoc executable
which is using this library. But because the library is not installed at
this moment (understand: not located in the final place
`/usr/lib/ghc-7.6.3/site-local/pandoc-1.12.1/`) the RPATH embeds its
*current* location, in my case
(see the output above). So as long as the library is present in this
folder, pandoc works, but obviously that is not working to distribute it. I
suppose this method is working for cabal-install because the library stays
at its place once built, which is not the case here: the library is moved
once built.

Also I suppose this problem doesn't appear with library-only package,
because each package generate only one `*.so` file (as far as I have seen),
so no need to link against another library of the same package at build

Up to my knowledge I see three solutions:

  1. Find a way to build and install in two passes, something like
separating in haskell-pandoc and haskell-pandoc-libs (first build and
install pandoc-libs, then build and install pandoc)
    - Requires to find a way to create separate PKGBUILDs for the same
hackage package. Elegant but complicated solution, so not very convenient.
  2. Try to modify the RPATH inside the executable
    - Seems to be possible, see [3], but complicated and not very elegant
  3. Change the linking paradigm to use /etc/ld.so.conf.d/* instead of the
embedded RPATH
    - Requires to put or link all `*.so` libraries into on place, and add a
`/etc/ld.so.conf.d/haskell.conf` file to ghc installation. The most
tractable solution imho.

Does anyone has remarks/suggestions/ideas/solutions about this problem?

Best regards,

[2] http://www.haskell.org/pipermail/arch-haskell/2013-October/004600.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/arch-haskell/attachments/20131101/b5ecfd8b/attachment.html>

More information about the arch-haskell mailing list