Date: Sat, 22 Jan 2000 15:34:40 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Jason Evans <jasone@canonware.com> Cc: Bill Swingle <unfurl@dub.net>, current@FreeBSD.ORG Subject: Re: even more breakage in current Message-ID: <Pine.BSF.4.21.0001221523330.731-100000@alphplex.bde.org> In-Reply-To: <20000121142251.D27689@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Jan 2000, Jason Evans wrote:
> On Fri, Jan 21, 2000 at 10:11:57AM -0800, Bill Swingle wrote:
>...
> > cc -DPROF -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D__DBINTERFACE_PRIVATE -DINET6 -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DYP -I/usr/obj/usr/src/i386/usr/include -I/usr/src/lib/libc/i386 -c /usr/src/lib/libc/../libc/i386/gen/_setjmp.S -o _setjmp.po
> > /tmp/ccg65684.s: Assembler messages:
> > /tmp/cco65681.s: Assembler messages:
> > /tmp/cco65681.s:361: Error: invalid character '(' in opcode
> > /tmp/ccg65684.s:361: Error: invalid character '(' in opcode
This happens when libc/i386/DEFS.h and libc/i386/gen/setjmp.S are current
(as of Jan 21) but <machine/asm.h> is out of date.
> I moved some definitions from src/lib/libc/i386/DEFS.h to
> src/sys/i386/include/asm.h. If the build system is looking at the
> installed version of asm.h rather than the version in the source tree, this
> error will occur. I did a 'make includes' during my testing, so I didn't
> have this problem.
>
> It's my understanding that the build system is supposed to be sophisticated
> enough to avoid such bootstrapping issues, but I don't understand it all
> that well. Can someone explain whether this is a bug in the build system,
> or if I should be doing something different?
Everything should just work in this case, provided <machine/asm.h> is up
to date. All you could do better is commit <machine/asm.h> first so that
there is no window of inconsistency.
> In any case, doing a 'make includes' will get you past this.
Don't use `make includes' unless you are familiar enough with the build
system not to need it. It _causes_ problems like this by defeating the
build system (it gives a set of includes that tends not to match the
libraries). It happens to fix the problem in this case (at least if you
install only <machine/asm.h>).
Test header changes using `NOCLEAN=1 make buildworld'. NOCLEAN is now
fairly robust.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0001221523330.731-100000>