maralorn
commented
3 years ago Sounds good to me, thank you for figuring this out!
Open nh2 opened 3 years ago
maralorn
commented
3 years ago Sounds good to me, thank you for figuring this out!
nh2
commented
3 years ago I asked on #ghc chat and got suggestions that this is probably not a good idea:
@mpickering says:
There are a lot of issues with the linker built into GHC, so TH will not work with nixpkgs provided GHC for some cases. If you need to dynamically load certain libraries, just look at the HLS issue tracker.
@adamse concurs:
I agree with mpickering that it will cause pain for TH and sometimes ghci.
My original question was:
I'm planning to switch the nixpkgs GHC buidls from defaulting to
DYNAMIC_GHC_PROGRAMS=YEStoNO, to get 4x faster-starting GHCs. Will this prevent the creation of.sofiles entirely, thus making dynamic linking impossible, or will-dynamic-toostill be active?
the latter part of which @adamse explained:
You can still build .so's (with or w/o -dynamic-too), but [concerns quoted above]
@mpickering explained that haskell-language-server distributes GHCs with Haskell libraries statically-linked in, and that this creates many problems for them. It is currently unclear to me why haskell-language-server does that then, as it seems that they could just as well provide a DYNAMIC_GHC_PROGRAMS=YES for download for e.g. VSCode users. I asked that upstream: https://github.com/haskell/haskell-language-server/issues/2000
I don't really understand why linking e.g. libHSfilepath-* statically into the ghc binary affects TemplateHaskell at all. If anybody could find a resource that we could link to from the GHC nix derivations, we could close this ticket as something we don't want to do.
nh2
commented
3 years ago I don't really understand why linking e.g.
libHSfilepath-*statically into the ghc binary affects TemplateHaskell at all. If anybody could find a resource that we could link to from the GHC nix derivations, we could close this ticket as something we don't want to do.
@mpickering / @adamse / @bgamari If you have time, could you help us out with a good explanation or upstream GHC ticket to link to?
adamse
commented
3 years ago I think the main issue is linking the RTS statically, this currently causes GHCi and TemplateHaskell to use the home grown runtime linker to load other haskell packages object code. I don't quite remember all the details here though.
I think that on some targets it would be possible to use dlopen instead of the ghc rts linker even with a statically linked rts (with ld's --dynamic-list for rts symbols), but this requires work on GHC and I understand that not all targets have a functioning dl library (musl?).
stale[bot]
commented
2 years ago I marked this as stale due to inactivity. → More info
NorfairKing
commented
5 months ago Definitely not stale.
GHC in nixpkgs is currently built with
DYNAMIC_GHC_PROGRAMS=YES. This links Haskell libraries dynamically into GHC, and makes GHC's startup slow.That in turn makes GHC a bit of a drag to use with nix, because even a simple
--versioncall is unnecessarily slow (e.g. when used from scripts or in interactive feedback loops).Here's a table of the startup time we're giving away:
--versiontime (s)DYNAMIC_GHC_PROGRAMS=YESDYNAMIC_GHC_PROGRAMS=NOFinally,
DYNAMIC_GHC_PROGRAMS=YESalso makes the nix package larger: 435 MB vs 411 MB for static.Click here to expand data:
In nixpkgs there is no benefit in linking Haskell libraries dynamically into programs. This is why the
haskell-modules/generic-builder.nixdefaults toenableSharedExecutables ? falsefor nix-built Haskell programs. We should do the same for GHC.CC @NixOS/haskell @domenkozar
Edit: We should not do that for now, see https://github.com/NixOS/nixpkgs/issues/129245#issuecomment-874241200.
Instead, new closing criteria for this issue:
enableSharedit in the GHC Nix derivation files.