Subject: Re: another 1.1 to 1.1B (i386) upgrade report...
To: None <current-users@NetBSD.ORG>
From: Mike Long <email@example.com>
Date: 04/02/1996 11:20:00
>Date: Fri, 29 Mar 1996 08:31:18 -0500
>From: "John F. Woods" <jfw@FunHouse.com>
>> But the day is coming when I would
>> like to be _able_ to build from source without encountering a discontinuity
>> in the life-graph of the binary/source world.]
>Yeah, I would LIKE that too, but it occurs to me that at least for GCC,
>you're just about guaranteed that it is not possible. GCC is outside
>the control of the NetBSD core group (unless you want them never to
>upgrade again, in which case maybe you can argue with all the people who
>want every single patch and point release thrown into the tree immediately),
>and it is structured so that a large number of its features are wired into
>the compiler source in a way that guarantees discontinuity (remember the
>recent _XF problem?).
I think the best solution for this is to add a bootstrap: target to
NetBSD's imported gcc, similar to gcc's standard bootstrap procedure
for gcc. 'make bootstrap' would make && make install cc and cc1,
clean them out, then make && make install all of gcc.
>So, aside from gcc (and that's a big aside, in more than one way!), it should
>take relatively little discipline to make source-only rebuilds *possible*,
>but I think making source-only rebuilds *automatic* for *everyone* is still
>not really practical.
A bootstrap target would be useful elsewhere, as well. For instance,
it could make src/usr.bin/lex/Makefile use initscan.c instead of
>Hmm. Yeah, ld also rears its ugly head every few months with sea changes,
>and some of the important changes can't be accomplished gracefully. (Well,
>I guess the least graceful changes have been in dynamic linking, so using
>static-linking to generate one's rebuild-kit might be sufficient.)
bootstrap builds could set LDSTATIC=-static, to prevent shared-library
problems. To speed up the process, we could also use NOMAN and
>Perhaps a reasonable compromise would be to accompany full releases with a
>"development kit" that comprises static-linked build tools sufficient to build
>a new source tree from scratch. This could even be created by some interested
>third party, rather than being a core release function.
This is another good solution.
Mike Long <firstname.lastname@example.org> <URL:http://www.shore.net/~mikel>
VLSI Design Engineer finger email@example.com for PGP public key
Analog Devices, CPD Division CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA (eq (opinion 'ADI) (opinion 'mike)) -> nil