From: David Holland <dholland-pkgtech%netbsd.org@localhost>
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.
Okay.
> 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 - http://cielonegro.org/
OpenPGP public key: 1024D/1A86EF72
Fpr: 5F3E 5B5F 535C CE27 8254 4D1A 14E7 9CA7 1A86 EF72
Attachment:
pgpoNvZhoK7na.pgp
Description: PGP signature