Magnus Therning | 31 Oct 21:26 2013

Cabal: --enable-shared and executables

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

--

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

The day after tomorrow is the third day of the rest of your life.
(Continue reading)

Albert Y. C. Lai | 31 Oct 22:16 2013
Picon

Re: Cabal: --enable-shared and executables

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 | 1 Nov 00:12 2013

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

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 <at> therning.org   jabber: magnus <at> therning.org
twitter: magthe               http://therning.org/magnus
(Continue reading)

Magnus Therning | 3 Nov 06:46 2013

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
(Continue reading)

Carter Schonwald | 3 Nov 07:27 2013
Picon

Re: 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 <magnus <at> therning.org> 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 <at> therning.org   jabber: magnus <at> 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Magnus Therning | 3 Nov 10:15 2013

Re: 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 <at> therning.org   jabber: magnus <at> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Albert Y. C. Lai | 3 Nov 23:05 2013
Picon

Re: 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 | 4 Nov 00:13 2013
Picon

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

On Sun, Nov 3, 2013 at 5:05 PM, Albert Y. C. Lai <trebla <at> vex.net> 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 <at> gmail.com                                  ballbery <at> sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Christiaan Baaij | 5 Nov 09:42 2013
Picon

Re: 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 <allbery.b <at> gmail.com> wrote:

> On Sun, Nov 3, 2013 at 5:05 PM, Albert Y. C. Lai <trebla <at> vex.net> 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 <at> gmail.com                                  ballbery <at> sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
Magnus Therning | 5 Nov 06:53 2013

Re: 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 <at> therning.org   jabber: magnus <at> therning.org
twitter: magthe               http://therning.org/magnus

The day after tomorrow is the third day of the rest of your life.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane