Cabal: --enable-shared and executables

Magnus Therning

31 Oct 2013 31 Oct '13

4:26 p.m.

We've had a discussion about DSOs on the arch-haskell mailing list[1] and it made me realise one thing: --enable-shared will cause the generation of DSOs for libraries, but it won't cause executables to be dynamically linked Is the only way to cause these executables to be dynamically linked against their dependencies to pass the -dynamic flag to ghc (e.g. via the --ghc-options flag when configuring the package)? That then raises the issue of finding the DSOs. Something that is discussed in the Ghc documentation[2]. However, the generated DSOs are correctly linked to their dependencies. I guess what I'm trying to get to is that it seems to me that Cabal only provides half the solution to DSOs; it solves generation, but not usage. Is that an observation that people agree with? Are there any plans to solve this (maybe it's already solved in 1.18)? /M [1]: http://www.haskell.org/pipermail/arch-haskell/2013-October/004599.html [2]: http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/using-shared-libs.htm... -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus The day after tomorrow is the third day of the rest of your life.

Attachments:

attachment.sig (application/pgp-signature — 198 bytes)

Show replies by date

Albert Y. C. Lai

31 Oct 31 Oct

5:16 p.m.

On 13-10-31 04:26 PM, Magnus Therning wrote:

...

We've had a discussion about DSOs on the arch-haskell mailing list[1] and it made me realise one thing:

--enable-shared will cause the generation of DSOs for libraries, but it won't cause executables to be dynamically linked

Is the only way to cause these executables to be dynamically linked against their dependencies to pass the -dynamic flag to ghc (e.g. via the --ghc-options flag when configuring the package)?

Have you seen --enable-executable-dynamic? It's there since cabal-install 0.14 or earlier. It is also available to Setup.hs since Cabal 1.14 or earlier, which came with GHC 7.4. Have you done a "cabal install --help | less" lately? Also "cabal configure --help | less".

Magnus Therning

7:12 p.m.

On Thu, Oct 31, 2013 at 05:16:11PM -0400, Albert Y. C. Lai wrote:

...

On 13-10-31 04:26 PM, Magnus Therning wrote:

...
We've had a discussion about DSOs on the arch-haskell mailing list[1] and it made me realise one thing:

--enable-shared will cause the generation of DSOs for libraries, but it won't cause executables to be dynamically linked

Is the only way to cause these executables to be dynamically linked against their dependencies to pass the -dynamic flag to ghc (e.g. via the --ghc-options flag when configuring the package)?

Have you seen --enable-executable-dynamic? It's there since cabal-install 0.14 or earlier. It is also available to Setup.hs since Cabal 1.14 or earlier, which came with GHC 7.4.

Have you done a "cabal install --help | less" lately? Also "cabal configure --help | less".

Ah, of course I ought to have checked the `cabal configure --help`. That flag seems to be what I was looking for indeed. It seems I've only found a shortcoming of the Ghc docs, not a shortcoming of Cabal :) /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.

Magnus Therning

3 Nov 3 Nov

1:46 a.m.

New subject: Cabal bug? (was Re: Cabal: --enable-shared and executables)

On Thu, Oct 31, 2013 at 05:16:11PM -0400, Albert Y. C. Lai wrote:

...

On 13-10-31 04:26 PM, Magnus Therning wrote:

...
We've had a discussion about DSOs on the arch-haskell mailing list[1] and it made me realise one thing:

--enable-shared will cause the generation of DSOs for libraries, but it won't cause executables to be dynamically linked

Is the only way to cause these executables to be dynamically linked against their dependencies to pass the -dynamic flag to ghc (e.g. via the --ghc-options flag when configuring the package)?

Have you seen --enable-executable-dynamic? It's there since cabal-install 0.14 or earlier. It is also available to Setup.hs since Cabal 1.14 or earlier, which came with GHC 7.4.

Have you done a "cabal install --help | less" lately? Also "cabal configure --help | less".

Now I have tried the `--enable-executable-dynamic` flag and have found one problem with it, it doesn't work that well for packages that have both executables and a library. I tried it on pandoc. Here's what I got: % file /usr/bin/pandoc % /usr/bin/pandoc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=bb046a49bb820ab4d592d154bd0a5064f40bba5b, stripped So far so good, but % pandoc --help pandoc: error while loading shared libraries: libHSpandoc-1.12.1-ghc7.6.3.so: cannot open shared object file: No such file or directory The DSO is installed though % pacman -Ql haskell-pandoc|grep libHSpandoc haskell-pandoc /usr/lib/ghc-7.6.3/site-local/pandoc-1.12.1/libHSpandoc-1.12.1-ghc7.6.3.so haskell-pandoc /usr/lib/ghc-7.6.3/site-local/pandoc-1.12.1/libHSpandoc-1.12.1.a haskell-pandoc /usr/lib/ghc-7.6.3/site-local/pandoc-1.12.1/libHSpandoc-1.12.1_p.a It just can't be found % ldd /usr/bin/pandoc|grep libHSpandoc libHSpandoc-1.12.1-ghc7.6.3.so => not found libHSpandoc-types-1.12.3-ghc7.6.3.so => /usr/lib/ghc-7.6.3/site-local/pandoc-types-1.12.3/libHSpandoc-types-1.12.3-ghc7.6.3.so (0x00007f60bf3e1000) The problem is that RPATH doesn't contain the location where the *installed* pandoc lib ends up, but only the location where the pandoc lib is *built*: % readelf -d /usr/bin/pandoc|grep RPATH|head 0x000000000000000f (RPATH) Library rpath: [/build/haskell-pandoc/src/pandoc-1.12.1/dist/build:/usr/lib/ghc-7.6.3/site-local/zip-archive-0.1.4:/usr/lib/ghc... Is there already a way to get Cabal to put in an RPATH such that an *installed* executable works correctly, or is this a fairly serious bug in Cabal? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Some operating systems are called 'user friendly', Linux however is 'expert friendly'.

Carter Schonwald

1:27 a.m.

New subject: Cabal bug? (was Re: Cabal: --enable-shared and executables)

could you file a bug report on the cabal issue tracker? github.com/haskell/cabal/issues :) On Sun, Nov 3, 2013 at 1:46 AM, Magnus Therning wrote:

...

On Thu, Oct 31, 2013 at 05:16:11PM -0400, Albert Y. C. Lai wrote:

...
On 13-10-31 04:26 PM, Magnus Therning wrote:

...
We've had a discussion about DSOs on the arch-haskell mailing list[1] and it made me realise one thing:

--enable-shared will cause the generation of DSOs for libraries, but it won't cause executables to be dynamically linked

Is the only way to cause these executables to be dynamically linked against their dependencies to pass the -dynamic flag to ghc (e.g. via the --ghc-options flag when configuring the package)?

Have you seen --enable-executable-dynamic? It's there since cabal-install 0.14 or earlier. It is also available to Setup.hs since Cabal 1.14 or earlier, which came with GHC 7.4.

Have you done a "cabal install --help | less" lately? Also "cabal configure --help | less".

Now I have tried the `--enable-executable-dynamic` flag and have found one problem with it, it doesn't work that well for packages that have both executables and a library.

I tried it on pandoc. Here's what I got:

% file /usr/bin/pandoc % /usr/bin/pandoc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=bb046a49bb820ab4d592d154bd0a5064f40bba5b, stripped

So far so good, but

% pandoc --help pandoc: error while loading shared libraries: libHSpandoc-1.12.1-ghc7.6.3.so: cannot open shared object file: No such file or directory

The DSO is installed though

% pacman -Ql haskell-pandoc|grep libHSpandoc haskell-pandoc /usr/lib/ghc-7.6.3/site-local/pandoc-1.12.1/ libHSpandoc-1.12.1-ghc7.6.3.so haskell-pandoc /usr/lib/ghc-7.6.3/site-local/pandoc-1.12.1/libHSpandoc-1.12.1.a haskell-pandoc /usr/lib/ghc-7.6.3/site-local/pandoc-1.12.1/libHSpandoc-1.12.1_p.a

It just can't be found

% ldd /usr/bin/pandoc|grep libHSpandoc libHSpandoc-1.12.1-ghc7.6.3.so => not found libHSpandoc-types-1.12.3-ghc7.6.3.so => /usr/lib/ghc-7.6.3/site-local/pandoc-types-1.12.3/ libHSpandoc-types-1.12.3-ghc7.6.3.so (0x00007f60bf3e1000)

The problem is that RPATH doesn't contain the location where the *installed* pandoc lib ends up, but only the location where the pandoc lib is *built*:

% readelf -d /usr/bin/pandoc|grep RPATH|head 0x000000000000000f (RPATH) Library rpath: [/build/haskell-pandoc/src/pandoc-1.12.1/dist/build:/usr/lib/ghc-7.6.3/site-local/zip-archive-0.1.4:/usr/lib/ghc...

Is there already a way to get Cabal to put in an RPATH such that an *installed* executable works correctly, or is this a fairly serious bug in Cabal?

/M

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

Some operating systems are called 'user friendly', Linux however is 'expert friendly'.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Magnus Therning

4:15 a.m.

New subject: Cabal bug? (was Re: Cabal: --enable-shared and executables)

On Sun, Nov 03, 2013 at 01:27:06AM -0500, Carter Schonwald wrote:

...

could you file a bug report on the cabal issue tracker? github.com/haskell/cabal/issues :)

Done, it became issue #1568 [1]. I'm hopeful it's a simple fix and that we can see a backport to 1.16 as well as a fix for 1.18 ;) /M [1]: https://github.com/haskell/cabal/issues/1568 -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I would rather use Java than Perl. And I'd rather be eaten by a crocodile than use Java. -- Trouser

Albert Y. C. Lai

5:05 p.m.

New subject: Cabal bug? (was Re: Cabal: --enable-shared and executables)

On 13-11-03 01:46 AM, Magnus Therning wrote:

...

Is there already a way to get Cabal to put in an RPATH such that an *installed* executable works correctly, or is this a fairly serious bug in Cabal?

It is usually desirable to set RPATH to libs' installation locations rather than libs' build trees, and I think I prefer it too. But the exception is during "cabal test", when you should test against libs in the build tree. It is somewhat a dilemma. It is, in fact, sad that we have to set RPATH at all, and we have to because Haskell libs are not common, and they are not dumped directly into /usr/lib and /usr/local/lib. (They are, instead, scattered over /usr/local/lib/p-n/ghc-m, for wide ranges of values of p, n, and m.) If not for this, we would set no RPATH, we would do nothing special for installations, and we just had to play with LD_LIBRARY_PATH or LD_RUN_PATH or something during testing. (I would, in fact, not mind that organization, if symlinks were set up directly in /usr/local/lib. Note: the filename is already libHSp-n-ghcm.so, it already records p, n, and m, there is no clash putting that name right into /usr/local/lib alongside siblings and cousins --- well, no more clash than the /usr/local/lib/p-n/ghc-m scheme.)

Brandon Allbery

6:13 p.m.

New subject: Cabal bug? (was Re: Cabal: --enable-shared and executables)

On Sun, Nov 3, 2013 at 5:05 PM, Albert Y. C. Lai wrote:

...

It is usually desirable to set RPATH to libs' installation locations rather than libs' build trees

May I note that this is system dependent? OS X compiles in full paths (and DYLD_LIBRARY_PATH overrides these, which is part of why it's much more dangerous than Linux's LD_LIBRARY_PATH). On the other end, I don't think Windows has much of an RPATH mechanism at all. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Christiaan Baaij

5 Nov 5 Nov

3:42 a.m.

New subject: Cabal bug? (was Re: Cabal: --enable-shared and executables)

Indeed I want to point out that dynamic library locations are already handled differently between OS X and Linux in GHC(-head), not just Cabal: http://ghc.haskell.org/trac/ghc/ticket/8266#comment:14 So perhaps there should be a 'proper' fix/design on how to deal with dynamic library location in both GHC and Cabal. -- Christiaan On Nov 4, 2013, at 12:13 AM, Brandon Allbery wrote:

...

On Sun, Nov 3, 2013 at 5:05 PM, Albert Y. C. Lai wrote: It is usually desirable to set RPATH to libs' installation locations rather than libs' build trees

May I note that this is system dependent? OS X compiles in full paths (and DYLD_LIBRARY_PATH overrides these, which is part of why it's much more dangerous than Linux's LD_LIBRARY_PATH). On the other end, I don't think Windows has much of an RPATH mechanism at all.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Magnus Therning

12:53 a.m.

New subject: Cabal bug? (was Re: Cabal: --enable-shared and executables)

On Sun, Nov 03, 2013 at 05:05:40PM -0500, Albert Y. C. Lai wrote:

...

On 13-11-03 01:46 AM, Magnus Therning wrote:

...
Is there already a way to get Cabal to put in an RPATH such that an *installed* executable works correctly, or is this a fairly serious bug in Cabal?

It is usually desirable to set RPATH to libs' installation locations rather than libs' build trees, and I think I prefer it too. But the exception is during "cabal test", when you should test against libs in the build tree. It is somewhat a dilemma.

Indeed, that is a bit of a problem. However, I'd argue that /installation/ of a package is the scenario to make as simple as possible. Forcing the use of LD_LIBRARY_PATH in order to run `cabal test` is much more acceptable to me than forcing its use to run an installed executable.

...

It is, in fact, sad that we have to set RPATH at all, and we have to because Haskell libs are not common, and they are not dumped directly into /usr/lib and /usr/local/lib. (They are, instead, scattered over /usr/local/lib/p-n/ghc-m, for wide ranges of values of p, n, and m.) If not for this, we would set no RPATH, we would do nothing special for installations, and we just had to play with LD_LIBRARY_PATH or LD_RUN_PATH or something during testing.

(I would, in fact, not mind that organization, if symlinks were set up directly in /usr/local/lib. Note: the filename is already libHSp-n-ghcm.so, it already records p, n, and m, there is no clash putting that name right into /usr/local/lib alongside siblings and cousins --- well, no more clash than the /usr/local/lib/p-n/ghc-m scheme.)

We have have been considering a scheme like this when packaging for Arch Haskell (inofficial packages for Arch Linux). Something along the lines of putting symlinks in /usr/lib/ghc-7.6.3/ and then drop a file in /etc/ld.so.conf.d/ that adds it to the runtime linker's search path. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus The day after tomorrow is the third day of the rest of your life.

4215

Age (days ago)

4220

Last active (days ago)

List overview

Download

9 comments

5 participants

participants (5)

Albert Y. C. Lai
Brandon Allbery
Carter Schonwald
Christiaan Baaij
Magnus Therning

Cabal: --enable-shared and executables

tags

participants (5)