Subject: Re: another 1.1 to 1.1B (i386) upgrade report...
To: None <current-users@NetBSD.ORG>
From: Mike Long <>
List: current-users
Date: 04/02/1996 11:20:00
>Date: Fri, 29 Mar 1996 08:31:18 -0500
>From: "John F. Woods" <>
>> 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 <>     <URL:>
VLSI Design Engineer         finger for PGP public key
Analog Devices, CPD Division          CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA       (eq (opinion 'ADI) (opinion 'mike)) -> nil