tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Updating plans of lang/ghc

From: David Holland <>
Subject: Re: Updating plans of lang/ghc
Date: Wed, 8 Jan 2014 06:21:10 +0000

>  > There are currently two competing plans for updating lang/ghc, namely
>  > lang/ghc-bootstrap and lang/ghc7. I think there are pros and cons for
>  > these plans but let me first clarify the starting point of wip/ghc
>  > bootstrap kits, which support the following 5 platforms:
>  > [snip]
> That's good information to have.
> The chief concern with the provenance of binary bootstrap blobs is
> whether the machine they were built on was adequately secured;
> anything built on an owned machine might be trojanized somehow, which
> is particularly problematic in the case of compilers. (And, well,
> there's also the possibility that the person who built them might have
> intentionally trojanized them, unlikely as that is.)
> Now that you're here we can hopefully sort this out satisfactorily --
> I have no desire to sink a lot of effort into updating ghc step-by-
> step if it can be avoided.
> [snip]

Well... I'm puzzled. Are you saying I have to prove that machines I
used to build my kits were not trojanized by any means? Obviously I
can't. No one on the earth can prove such things.

>  > The one thing I am concerning about is that users will have to find
>  > and install a binary package if they want to build lang/ghc
>  > themselves, otherwise they'll end up standing in front of a
>  > circular dependency.
> The idea is that ghc-bootstrap depends on ghc (used for building) but
> ghc does *not* depend on ghc-bootstrap; instead once in a while
> someone takes the ghc-bootstrap package from the build host and posts
> it as a distfile in MASTER_SITE_LOCAL, and updates the distfile
> information in the main ghc package. I think this avoids most of the
> problems that otherwise come up.

I see. That sounds good.

> There is one problem with the current ghc-bootstrap (other than it
> being an old ghc), which is that it is dynamically linked against
> libreadline and libgmp. This means that the next time readline and/or
> gmp get their major versions bumped, the whole thing crashes out.
> I was intending to correct this before the 2013q4 branch, but wiz cut
> the branch without advance warning so I didn't get it done in time.
> Also I ran into problems: it seems that disabling readline and telling
> it to build with its included gmp (best available option in 6.8) is
> not sufficient to produce an output package that doesn't depend on
> pkgsrc readline and gmp. And it's hard to tell if it will be able to
> build a new ghc this way anyhow -- I suppose I can create a chroot for
> the purpose and artificially bump the readline and gmp major versions.
> The conclusion I'd come to was that I should include copies of the
> library images in the bootstrap kit and hope that it can be sorted out
> with LD_PRELOAD when the time comes.

How about removing *.so from ${BUILDLINK_DIR}/lib to get the linker
pick up only static libraries? Even though recent GHC comes with
shared Haskell libraries by default, which can't be linked with static
C libraries, they can be disabled anyway.

>  > But how about ones that
>  > were covered by lang/ghc but not by wip/ghc, namely Darwin/i386,
>  > OpenBSD/i386 and SunOS/i386? Can anyone do the stepwise upgrade or
>  > cross-compilation of 7.6.x for them? If not, is it OK for us to drop
>  > support for these ones?
> jperkin@ says the Solaris i386 one doesn't actually work, so it can be
> dumped. I think he's using wip/ghc and made Solaris bootstrap kits for
> it.


> As for OpenBSD and MacOS... it will be much easier for someone to
> crosscompile a recent version when/if they get around to it than to do
> the long upgrade series. So if we're going to move to your bootstrap
> kits, I think we can drop those too.

I second that.
 - PHO -               
OpenPGP public key: 1024D/1A86EF72
Fpr: 5F3E 5B5F 535C CE27 8254  4D1A 14E7 9CA7 1A86 EF72

Attachment: pgpoNvZhoK7na.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index