[arch-haskell] devtools version problem

[Fabien Dubosson]

> I'll start with asking on haskell-cafe, because it sure looks like
> this problem ought to be solved by Cabal and not by us.

Yep I saw your mail, and also the first response. Since I read the answer
after I wrote this message, I added some comment in curly braces regarding
to this new information. I'll try later to use the
`--enable-executable-dynamic` instead of `--ghc-options=-dynamic`.


> Exactly, everything named haskell-* are library packages, only a few
> packages are pure tool packages (e.g. cblrepo, git-annex).  Pure tool
> packages make use of makedepends.  The relevant lines in cblrepo are
> found in Util.Translation, lines 302 and 303 in the current version
> (
https://github.com/magthe/cblrepo/blob/master/src/Util/Translation.hs#L302).

Ok, and if we want to use shared libraries, it will just require us to
modify this part to put all the dependences only in `depends` right? Also
will the static libraries still be needed if all packages use shared
libraries?


> So, while it's possible to pass --enable-shared to build shared libs
> when configuring the package, it won't actually *use* shared libs.
> -dynamic is a flag for GHC, correct?

Yes correct. Actually I had to add ghc "--disable-library-profiling" flag
too because it was complaining that `base` shared libraries where not built
with profiling capabilities (e.g. see the first comment here:
http://ghc.haskell.org/trac/ghc/ticket/5021). {Regarding the first answer
to your Haskell-Cafe message, using `--enable-executable-dynamic` will
maybe solve this issue?!? To be verified...}


> What effects does passing --ghc-options at `Setup.hs configure` have
> on any `ghc-options:` field present in the .cabal?

I don't know, but sure this's a point to verify! {Again using cabal flag
`--enable-executable-dynamic` will certainly permit cabal to handle itself
this precise situation.}


> Interestingly the shared libs don't seem to suffer from this problem;
> run `ldd´ on one of the shared libs in a package to see what I mean.
>
> It sure looks like cabal has solved the problem halfway only.

Good idea to check the libs! I just had a look at them. The difference imho
is they are using the first option with RPATH. This is confirmed by running:

    $ readelf --dynamic /usr/lib/ghc-7.6.3/site-local/xmonad-0.11/
libHSxmonad-0.11-ghc7.6.3.so
    [[...]]
 0x000000000000000f (RPATH)              Library rpath:
[/usr/lib/ghc-7.6.3/site-local/utf8-string-0.3.7:/usr/lib/ghc-7.6.3/process-1.1.0.2:/usr/lib/ghc-7.6.3/site-local/mtl-2.1.2:/usr/lib/ghc-7.6.3/site-local/transformers-0.3.0.0:/usr/lib/ghc-7.6.3/site-local/extensible-exceptions-0.1.1.4:/usr/lib/ghc-7.6.3/directory-1.2.0.1:/usr/lib/ghc-7.6.3/unix-2.6.0.1:/usr/lib/ghc-7.6.3/bytestring-0.10.0.2:/usr/lib/ghc-7.6.3/time-1.4.0.1:/usr/lib/ghc-7.6.3/filepath-1.3.0.1:/usr/lib/ghc-7.6.3/site-local/X11-1.6.1.1:/usr/lib/ghc-7.6.3/site-local/data-default-0.5.3:/usr/lib/ghc-7.6.3/site-local/data-default-instances-old-locale-0.0.1:/usr/lib/ghc-7.6.3/old-locale-1.0.0.5:/usr/lib/ghc-7.6.3/site-local/data-default-instances-dlist-0.0.1:/usr/lib/ghc-7.6.3/site-local/dlist-0.5:/usr/lib/ghc-7.6.3/site-local/data-default-instances-containers-0.0.1:/usr/lib/ghc-7.6.3/containers-0.5.0.0:/usr/lib/ghc-7.6.3/deepseq-1.3.0.1:/usr/lib/ghc-7.6.3/array-0.4.0.1:/usr/lib/ghc-7.6.3/site-local/data-default-instances-base-0.0.1:/usr/lib/ghc-7.6.3/site-local/data-default-class-0.0.1:/usr/lib/ghc-7.6.3/base-4.6.0.1:/usr/lib/ghc-7.6.3/integer-gmp-0.5.0.0:/usr/lib/ghc-7.6.3/ghc-prim-0.3.0.0:/usr/lib/ghc-7.6.3]
    [[...]]

All the paths are embedded into the libraries. In fact it is possible to
use the same principle to build executable, it is even the default way (I
passed `-dynload=deploy` to override and use LD_LIBRARY_PATH instead). I
just understand why this was not working with `pandoc` when I was using
RPATH the first time:
  1. To begin, the library is built in the folder
`src/<pkgname>/dist/build/`
  2. Then the executable is build on the top of shared libraries. But
because the pandoc library is in the `src/<pkgname>/dist/build/` folder
(because it is not installed at building time) the RPATH include this path
instead of the path where the library will be found when installed. And at
run time when the pandoc folder is cleared it doesn't found any longer the
library. So I don't know if there is a way to solve this problem, that what
I have switched to LD_LIB based solution. {I must also verify if this
situation persists with `--enable-executable-dynamic`, but I suspect it
will still be present because cabal can not know in advance where the
library will be put}.


> I think the /usr/lib/ghc-7.6.3/shared folder is as good a place as
> any.  IMHO we shouldn't place the Haskell libs straight into /usr/lib.
> Then the easiest thing would be to put the haskell-ldconf file into
> ghc itself, since each lib package depends on ghc anyway.  Of course,
> this highlights one aspect to consider before going down the path of
> using shared libs for pure tools: installing such a package will bring
> with it all libs it depends on as well as ghc, while at the moment it
> is completely free standing.

I see now more clearly the two different options:
  1. Use RPATH referencing, this is done at build time, but requires to
solve the linking problem cited above.
  2. Use LD_LIBRARY_PATH referencing, this requires to regroup all shared
libraries into one place.

Does someone know how most archlinux packages handle that? LD or RPATH?

> However, I think using shared libs for executables contained in libs
> packaged, e.g. /usr/bin/pandoc from haskell-pandoc, clearly is a good
> thing.

I agree. All this maybe not brings a lot of advantages (maybe just size?),
but I like things done well and in a consistent way :)

Regards,
Fabien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/arch-haskell/attachments/20131031/48a9e306/attachment-0001.html>