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@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus If voting could really change things it would be illegal.