I'm trying to build a minimal GHC 7.8.3 on Debian Wheezy with only dynamic libraries (this is for a system where disc space is scarce). I'm using this build.mk: GhcRTSWays = thr GhcLibWays = dyn HADDOCK_DOCS = NO DYNAMIC_BY_DEFAULT = YES GhcDynamic = YES Tried with and without GhcDynamic (asked on beginners how it's different to DYNAMIC_GHC_PROGRAMS but still waiting for an answer). It gets near the end of the build, then fails with: HC [stage 1] ghc/stage2/build/Main.dyn_o HC [stage 1] ghc/stage2/build/tmp/ghc-stage2 /usr/bin/ld: cannot find -lHSrts_thr-ghc7.8.3 collect2: error: ld returned 1 exit status make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 make: *** [all] Error 2 If I build with only static libraries, everything seems to work OK.
As far as I'm aware, Dynamic-by-default GHC is actually broken, and I
don't know for how long this has been the case.
For some history: originally when all this was being decided to try
and fix the linker issues in GHC, dynamic by default was considered an
option, but was rejected in favor of DynamicGhcPrograms. Why was it
rejected? Well, dynamic by default particularly hurts 32bit x86, which
suffers from a very pathetic set of registers, and dynamic programs
steal one of these for the GOT (%ebx IIRC).
On the other hand, DynamicGhcPrograms instead means GHC builds
everything statically, *except itself*, which it builds as a
dynamically linked executable. The idea is you dynamically link GHC
itself to fix linker issues, and end-user programs remain static,
which is the expected mode of operation.
In all honesty, we should probably remove any traces of
DYNAMIC_BY_DEFAULT unless someone is actively interested in it, since
it's bitrotten at this point.
On Mon, Oct 20, 2014 at 7:53 AM, Jeremy
I'm trying to build a minimal GHC 7.8.3 on Debian Wheezy with only dynamic libraries (this is for a system where disc space is scarce). I'm using this build.mk:
GhcRTSWays = thr GhcLibWays = dyn HADDOCK_DOCS = NO DYNAMIC_BY_DEFAULT = YES GhcDynamic = YES
Tried with and without GhcDynamic (asked on beginners how it's different to DYNAMIC_GHC_PROGRAMS but still waiting for an answer). It gets near the end of the build, then fails with:
HC [stage 1] ghc/stage2/build/Main.dyn_o HC [stage 1] ghc/stage2/build/tmp/ghc-stage2 /usr/bin/ld: cannot find -lHSrts_thr-ghc7.8.3 collect2: error: ld returned 1 exit status make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 make: *** [all] Error 2
If I build with only static libraries, everything seems to work OK.
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
Austin Seipp
As far as I'm aware, Dynamic-by-default GHC is actually broken, and I don't know for how long this has been the case.
For some history: originally when all this was being decided to try and fix the linker issues in GHC, dynamic by default was considered an option, but was rejected in favor of DynamicGhcPrograms. Why was it rejected? Well, dynamic by default particularly hurts 32bit x86, which suffers from a very pathetic set of registers, and dynamic programs steal one of these for the GOT (%ebx IIRC).
On the other hand, DynamicGhcPrograms instead means GHC builds everything statically, *except itself*, which it builds as a dynamically linked executable. The idea is you dynamically link GHC itself to fix linker issues, and end-user programs remain static, which is the expected mode of operation.
Thank you for the detailed explanation (although I still don't understand why DYNAMIC_BY_DEFAULT by default wasn't kept for x64.) Where does GhcDynamic fit into this?
Sorry, I confused 'DynamicGhcPrograms' merely with 'DynamicGhc'. In
other words: DynamicGhc means exactly what I said before - dynamic
GHC, static everything else.
As for the reason why the switch wasn't made for x86, I was not privvy
to the decision at the time, but I imagine it's one of consistency. To
ship a x64 GHC with these features (where it was acceptable) but not a
32bit one means essentially you force 32bit users into one of two
situations:
- Your compiled program may not work in GHCi, or at all in some
corner cases, and most of the bugs that were there are effectively
unfixed.
- Your compiled program suffers a noticeable performance hit, due to
register theft.
Which is rather unfortunate. On the other hand, if you dynamically
link GHC only, only GHC itself pays a hit on the dynamic linking, and
your remaining programs are unaffected.
On Mon, Oct 20, 2014 at 9:32 AM, Jeremy
Austin Seipp
writes: As far as I'm aware, Dynamic-by-default GHC is actually broken, and I don't know for how long this has been the case.
For some history: originally when all this was being decided to try and fix the linker issues in GHC, dynamic by default was considered an option, but was rejected in favor of DynamicGhcPrograms. Why was it rejected? Well, dynamic by default particularly hurts 32bit x86, which suffers from a very pathetic set of registers, and dynamic programs steal one of these for the GOT (%ebx IIRC).
On the other hand, DynamicGhcPrograms instead means GHC builds everything statically, *except itself*, which it builds as a dynamically linked executable. The idea is you dynamically link GHC itself to fix linker issues, and end-user programs remain static, which is the expected mode of operation.
Thank you for the detailed explanation (although I still don't understand why DYNAMIC_BY_DEFAULT by default wasn't kept for x64.)
Where does GhcDynamic fit into this?
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
So out of GhcDynamic, DYNAMIC_GHC_PROGRAMS, and DYNAMIC_BY_DEFAULT, which is broken, and what's the difference between GhcDynamic and DYNAMIC_GHC_PROGRAMS? This is getting somewhat confusing.
(Sorry for resend; also hitting the list this time).
GhcDynamic is really a variable set by the build system which is
propagated and used to control various other 'things that happen'
during the build, in the case GHC is dynamically linked.
On the other hand, DYNAMIC_GHC_PROGRAMS and DYNAMIC_BY_DEFAULT are the
actual options you may set in your build configuration to control what
happens. In other words, these two variables actually control what
will occur; GhcDynamic is just a detail of the build system to push
some information around, in the case you choose an option where GHC is
dynamically linked (you can certainly choose NO for both of these
options, which means 'GhcDynamic' will be false).
On Mon, Oct 20, 2014 at 9:44 AM, Jeremy
So out of GhcDynamic, DYNAMIC_GHC_PROGRAMS, and DYNAMIC_BY_DEFAULT, which is broken, and what's the difference between GhcDynamic and DYNAMIC_GHC_PROGRAMS? This is getting somewhat confusing.
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
participants (2)
-
Austin Seipp -
Jeremy