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