Hi guys, I've made some tests with --enable-shared, and the good news is that it works great. The bad news is that Cabal doesn't honor the flag when building executables. Apparently, this is a known issue: http://hackage.haskell.org/trac/hackage/ticket/600 A work-around that has been suggested is to specify --ghc-opt=-dynamic for builds that contain executables, but this solution feels kind of hack'ish. On the other hand, shared linkage cuts down binary size a lot, which is good. How do you feel about this issue? Any preferences? Take care, Peter
On 27/10/10 19:11, Peter Simons wrote:
Hi guys,
I've made some tests with --enable-shared, and the good news is that it works great. The bad news is that Cabal doesn't honor the flag when building executables. Apparently, this is a known issue:
http://hackage.haskell.org/trac/hackage/ticket/600
A work-around that has been suggested is to specify --ghc-opt=-dynamic for builds that contain executables, but this solution feels kind of hack'ish. On the other hand, shared linkage cuts down binary size a lot, which is good.
How do you feel about this issue? Any preferences?
My gut says it's pointless to add --enable-shared if we don't also make sure executables are made to use shared libs. Would it be possible to somehow configure ghc in Arch to do all of this, both for libs and the hack for exes, automatically? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
The packages in extra and community are built with enabled-shared. I find
this useful because I then have the option of linking dynamically against
them in things I compile myself. I was hoping that option would get enabled
in the PKGBUILDs generated by cabal2arch.
-Leif
On Wed, Oct 27, 2010 at 12:59 PM, Magnus Therning
On 27/10/10 19:11, Peter Simons wrote:
Hi guys,
I've made some tests with --enable-shared, and the good news is that it works great. The bad news is that Cabal doesn't honor the flag when building executables. Apparently, this is a known issue:
http://hackage.haskell.org/trac/hackage/ticket/600
A work-around that has been suggested is to specify --ghc-opt=-dynamic for builds that contain executables, but this solution feels kind of hack'ish. On the other hand, shared linkage cuts down binary size a lot, which is good.
How do you feel about this issue? Any preferences?
My gut says it's pointless to add --enable-shared if we don't also make sure executables are made to use shared libs.
Would it be possible to somehow configure ghc in Arch to do all of this, both for libs and the hack for exes, automatically?
/M
-- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Hi Leif,
The packages in extra and community are built with enabled-shared. I find this useful because I then have the option of linking dynamically against them in things I compile myself. I was hoping that option would get enabled in the PKGBUILDs generated by cabal2arch.
this is a good point. Cabal may not yet take advantage of shared libraries, but ArchLinux users of those libraries very well might. My feeling is that a binary repository should include shared libraries. We cannot make that change lightly, though, because our PKGBUILDs for executables declare their dependencies as $makedepends, based on the assumption that they're linked statically. This wouldn't be true, if those binaries link a dynamic GHC run-time, etc. It sounds like we could set --enable-shared for library builds, but we'd have to set --disable-shared for builds that involve executables. The alternative is to upgrade $makedepends to $depends. Am I missing something? Take care, Peter
On 2010/10/31 Peter Simons
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 ? -- Rémy.
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
participants (4)
-
Leif Warner -
Magnus Therning -
Peter Simons -
Rémy Oudompheng