<div dir="ltr"><div>> 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.</div><div><br></div><div>There once was a sizeable patch to Haddock to switch from xhtml to Lucid, </div><div>and it was rejected, seemingly, solely on the grounds that Lucid can't be added to boot libraries [1].</div><div>Since then Lucid dropped the heavier part of its dependency tree, so it's maybe not an issue anymore,</div><div>but my point is that there's more to this story than what you mentioned: the need for keeping Haddock and HPC's</div><div>dependencies in the set of boot libraries may slow down development of those tools. <br></div><div><br></div><div>[1]: <a href="https://github.com/haskell/haddock/pull/1598#issuecomment-1621765685" target="_blank">https://github.com/haskell/haddock/pull/1598#issuecomment-1621765685</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 10, 2024 at 12:10 PM Andreas Klebinger via ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</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">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>
</blockquote></div>