[arch-haskell] Re: What to do about --enable-shared?

[Peter Simons]

Hi Rémy,

 >> It sounds like we could set --enable-shared for library builds, but we'd
 >> have to set --disable-shared for builds that involve executables.
 >
 > I don't understand this part, even if "enable-build" made it create
 > dynamically linked programs, that would not seem to be a problem since we
 > already have a distinction:
 >
 > - libraries -> enable-shared + $depends
 > - programs -> no options + $makedepends
 >
 > Am I also missing something?

actually, you are right. Executables that depend on other libraries list
them in $depends, so these builds deal fine with dynamic linking.

The situation is different, though, when executables have no (visible)
library dependencies. For example, the cabal file for hasktags generates the
following output:

 | pkgname=hasktags
 | pkgver=0.68
 | pkgrel=1
 | makedepends=('ghc')
 | depends=('gmp')

This build considers GHC and its base libraries build-time dependencies,
which would be wrong if dynamic linking were enabled.

Now, this is not an issue with our current GHC 6.12.3, because it doesn't
use dynamic libraries unless it's explicitly told to. In case of a compiler
update, however, hasktag's PKGBUILD might be wrong, because GHC 7.0 may very
well enable dynamic linking by default, and then GHC's libraries will be
run-time dependencies.

Anyway, the reality is that [extra] and [community] ship Haskell libraries
built with --enable-shared already. IMHO, this situation gives us a strong
incentive to set --enable-shared for all other libraries as well. As long as
our compiler of choice is GHC 6.12.3, we don't have to worry about shared
libraries as far as excutables are concerned, but eventually we will have to
figure that out, too.

Does that sound reasonable?

Take care,
Peter