<div dir="ltr">> The `haddock` executable must be dynamically linked as it must compile<br><div>
source files.</div><div><br></div><div>Is this still true in the post-hi-haddock world? I thought we removed the code path in cabal that needed that, so recent versions of haddock shouldn't need it either?</div><div><br></div><div>M<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 11, 2024 at 9:41 AM Matthew Pickering <<a href="mailto:matthewtpickering@gmail.com">matthewtpickering@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The `haddock` executable must be dynamically linked as it must compile<br>
source files. It is much more robust to use dynamic linking when<br>
loading dependencies for TH evaluation than static linking. HLS is<br>
dynamically linked for the same reason.<br>
<br>
As such we have to distribute at least shared libraries for<br>
dependencies for haddock etc. It seems therefore that we might as well<br>
advertise these libraries are available in the package database. The<br>
things that we definitely have to advertise in the package database<br>
are `Cabal` and `ghc` and dependencies.<br>
<br>
The point about which libraries are boot libraries is a separate one.<br>
If you are developing a library which is a boot library then you are<br>
restricted to a small set of dependencies. Additional dependencies<br>
introduce a large amount of friction due to the coordindation needed<br>
during a release process. Anyone is free to develop their own<br>
libraries which use whichever dependencies they wish in user-space.<br>
<br>
Cheers,<br>
<br>
Matt<br>
<br>
On Wed, Jul 10, 2024 at 5:55 PM Hécate via ghc-devs<br>
<<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>> wrote:<br>
><br>
> Thanks a lot for the clarification Andreas.<br>
><br>
> So, the present situation is that we seem to have an implicit set of<br>
> packages that are readily available to users of ghc and ghci, but which<br>
> serve no direct goal for the end-user, and whose presence is fairly<br>
> arbitrary.<br>
><br>
> In light of the recent discussions about the mental model of<br>
> dependencies, cabal and GHC, I was wondering if anything was keeping us<br>
> expose these packages the user does not explicitly download.<br>
><br>
> I will take some time to see how to switch to (haskell-)static linking<br>
> for distribution releases.<br>
><br>
> Have a nice day,<br>
><br>
> Hécate<br>
><br>
> Le 10/07/2024 à 18:10, Andreas Klebinger via ghc-devs a écrit :<br>
> > I think they could be statically linked. But those boot libraries don't<br>
> > change much and generally<br>
> > don't really cause us nor users pain so it seems like there is little<br>
> > reason to do so to me.<br>
> ><br>
> > > Surely the size of binaries can't be the only concern, otherwise we'd<br>
> > use upx¹ on them when distributing them.<br>
> ><br>
> > I believe Ben experimented with executable compression tools in the past<br>
> > with little success.<br>
> > But there were segfaults, executables being flagged by antivirus and<br>
> > perhaps more issues I forgot<br>
> > which just made using it unrealistic at the time.<br>
> ><br>
> > But perhaps the tooling has matured in the meantime.<br>
> ><br>
> > Since our distributions are already compressed purely for *distribution*<br>
> > purposes I would expect the gains there to be rather slim anyway.<br>
> ><br>
> > So it's not really that we don't care about size, just that these tools<br>
> > seemed not reliable enough for the benefits they offer in the past.<br>
> ><br>
> > Am 10/07/2024 um 11:01 schrieb Hécate via ghc-devs:<br>
> >> Hi devs,<br>
> >><br>
> >> I had a chat earlier today with someone and found myself unable to<br>
> >> explain the reason why GHC came with boot dependencies like xhtml,<br>
> >> that are dependencies of Haddock and HPC.<br>
> >><br>
> >> Obviously, the binaries are (haskell-)dynamically linked when<br>
> >> distributed, but what is the reason why haddock, hpc, etc can't be<br>
> >> (haskell-)statically linked when distributed?<br>
> >><br>
> >> Surely the size of binaries can't be the only concern, otherwise we'd<br>
> >> use upx¹ on them when distributing them.<br>
> >><br>
> >> Cheers,<br>
> >><br>
> >> Hécate<br>
> >><br>
> >><br>
> >> 1: <a href="https://upx.github.io" rel="noreferrer" target="_blank">https://upx.github.io</a><br>
> >><br>
> > _______________________________________________<br>
> > ghc-devs mailing list<br>
> > <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
><br>
> --<br>
> Hécate ✨<br>
> 🐦: @TechnoEmpress<br>
> IRC: Hecate<br>
> WWW: <a href="https://glitchbra.in" rel="noreferrer" target="_blank">https://glitchbra.in</a><br>
> RUN: BSD<br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>