[arch-haskell] Dynamic executables and RPATH

[Magnus Therning]

On Fri, Nov 01, 2013 at 01:04:44PM +0100, Fabien Dubosson wrote:
> Hi,
> 
> 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?).

You did not do something wrong at all.  I was a bit to eager pushing
the change and seem to have missed in testing the results of that
change properly.

> 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
> `/home/fabien/archlinux/habs/haskell-pandoc/src/pandoc-1.12.1/dist/build`
> (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.

Which explains why my crude initial test succeeded, I didn't bother
removing the build folder after installation.

> 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 time.

That seems logical.  It also wouldn't be a problem for exe-only
packages since then there is no local lib built.

> 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 solution.
>   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?

Well, to me it seems that Cabal is broken here.  On `configure` Cabal
is told where the built lib will end up so it would be more correct to
put in an RPATH to that location rather than to the build location of
the lib.  I'll point this out on the haskell-cafe (if no one's beat me
to it :).

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus

If voting could really change things it would be illegal.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/arch-haskell/attachments/20131103/e0e47541/attachment.sig>