From owner-freebsd-current Mon Sep 17 2:47:22 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 353D137B409; Mon, 17 Sep 2001 02:47:16 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA11839; Mon, 17 Sep 2001 19:47:09 +1000 Date: Mon, 17 Sep 2001 19:46:42 +1000 (EST) From: Bruce Evans X-X-Sender: To: Ruslan Ermilov Cc: Jordan Hubbard , Subject: Re: Build problem in -current In-Reply-To: <20010917101303.C48120@sunbay.com> Message-ID: <20010917190812.P41875-100000@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 17 Sep 2001, Ruslan Ermilov wrote: > On Sat, Sep 15, 2001 at 03:57:26AM +1000, Bruce Evans wrote: > > On Wed, 5 Sep 2001, Ruslan Ermilov wrote: > > > > > On Wed, Sep 05, 2001 at 09:44:05PM +1000, Bruce Evans wrote: > > > [...] > > > What do I hear?! Are we required to support non-FreeBSD hosts at the > > > Makefile level? That would be too conservative, and is already broken > > > in many other ways. > > > > > > > It is unreasonable to expect the target source strtofflags.c to be > > > > compilable in the host environment. > > > > > > > But we can at least try (with high probability of success) -- this is > > > better than the current breakage Jordan observes. > > > > I think it's easier to make a fairly general case work than fix special > > cases as they turn up. > > > But we only need to "fix" these special (bootstrapping) cases. By "special cases", I meant all problems that turn up for FreeBSD-u.v.w hosts and FreeBSD-x.y.z targets (u >= 2, x >= 2). There will be about as many of them as for the more general case of a general POSIX.[1-2]-1990ish host and a FreeBSD-x.y.z target. > > > > The correct fix is to not support file flags in the bootstrap > > > > version of install. > > > > > > > But we now always bootstrap install(1). Not including support for > > > file flags here would mean "no support for file flags during the > > > installworld". > > > > That's certainly a problem. I still don't see the point of the runtime > > test to avoid using strtofflags.c. strttofflags.c is just as portable as > > the xinstall sources (modulo the dependency on declaring the > > things in it, if WARNS is turned on). > > > Probably because you build your world static? :-) In a non-static > case (like for the normal ``make buildworld''), strtofflags.c is the > version that is getting compiled into, if used unconditionally. Nah, the static case has better error checking, so it is just more likely to break if strtofflags is in libc.a and is misimplemented so that it conflicts with the local version :-). Tools should be linked static anyway, if possible. (This may not be possible. A POSIX or even a FreeBSD-2+ host might not have any static libraries. Or it might not have any dynamic libraries. A general POSIX host might not even have a -static compiler flag to control this. However, the details can be hidden in the handling of the NOSHARED flag. buildworld should simply set this flag for tools like it used to.) > If there would be a way to distinguish before bootstrapping and normal > builds, I would definitely agree. There is the (slightly misnamed) "WORLD" flag. mtree/Makefile uses this flag, but setting of it is broken. ISTR that there used to be a flag that said that the build-tools target is being built. > > Something as simple as this might work as well: > > Index: Makefile.inc1 > =================================================================== > RCS file: /home/ncvs/src/Makefile.inc1,v > retrieving revision 1.215 > diff -u -r1.215 Makefile.inc1 > --- Makefile.inc1 2001/08/29 09:11:03 1.215 > +++ Makefile.inc1 2001/09/17 07:13:50 > @@ -180,7 +180,7 @@ > # bootstrap-tool stage > BMAKEENV= ${BOOTSTRAPENV} > BMAKE= ${BMAKEENV} ${MAKE} -f Makefile.inc1 -DNOHTML -DNOINFO \ > - -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED > + -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -DBOOTSTRAPPING > > # build-tool stage > TMAKEENV= MAKEOBJDIRPREFIX=${OBJTREE} \ Hmm, we already use NOSHARED for BMAKE and XMAKE. We just don't use it (explicitly?) for TMAKE (and of course for non-tools). My version uses -DNOSHARED -DWORLD explicitly for BMAKE, TMAKE and XMAKE. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message