The reason for non-GHC boot dependencies

Michael Peyton Jones me at michaelpj.com
Thu Jul 11 09:28:46 UTC 2024


> The `haddock` executable must be dynamically linked as it must compile
source files.

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?

M

On Thu, Jul 11, 2024 at 9:41 AM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

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


More information about the ghc-devs mailing list