Re: cvs commit: src/contrib/binutils/ld/emultempl elf32.em
[Ref. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=574034+0+current/cvs-all] Just had a build of today's -CURRENT die during the stage 3: cross tools part: === ld ln -sf /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/emultempl/astring.sed stringify.sed sh /usr/src/gnu/usr.bin/binutils/ld/genscripts.sh /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld \/usr/lib\ i386-unknown-freebsd i386-unknown-freebsd i386-unknown-freebsd elf_i386 elf_i386 i386-unknown-freebsd echo extern ld_emulation_xfer_type ld_elf_i386_emulation; ldemul-list.h echo #define EMULATION_LIST ld_elf_i386_emulation, 0 ldemul-list.h yacc -d -o ldgram.c /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldgram.y lex -t /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlex.l ldlex.c rm -f .depend mkdep -f .depend -a-D_GNU_SOURCE -I- -I. -I/usr/src/gnu/usr.bin/binutils/ld/i386 -I/usr/src/gnu/usr.bin/binutils/ld -I/usr/src/gnu/usr.bin/binutils/ld/../libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/include -DDEFAULT_EMULATION=\elf_i386\ -DTARGET=\i386-unknown-freebsd\ -DSCRIPTDIR=\/usr/obj/usr/src/i386/usr/libdata\ -I/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld -DVERSION=\2.10.1\ -DBFD_VERSION=\2.10.1\ -I/usr/obj/usr/src/i386/usr/include eelf_i386.c /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldcref.c /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldctor.c /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldemul.c /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldexp.c /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldfile.c ldgram.c /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c ldlex.c /usr/src! /gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmisc.c /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldver.c /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldwrite.c /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/lexsup.c /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/mri.c eelf_i386.c:158: elf-hints.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/ld. *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils. This is on: FreeBSD localhost 5.0-CURRENT FreeBSD 5.0-CURRENT #51: Wed May 2 16:24:51 PDT 2001 [EMAIL PROTECTED]:/common/C/obj/usr/src/sys/compile/LAPTOP_30W i386 Recent CVSups: CVSup started from cvsup14.freebsd.org at Wed May 2 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Wed May 2 03:53:01 PDT 2001 CVSup started from cvsup14.freebsd.org at Thu May 3 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Thu May 3 03:52:25 PDT 2001 A find from /usr/src showed that elf-hints.h is in /usr/src/include, with a timestamp of 05:34 this morning (when I ran the cvs update). A similar check of /usr/obj turns up empty... should it be getting copied somewhere, perhaps? Thanks, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/contrib/binutils/ld/emultempl elf32.em
On Thu, May 03, 2001 at 07:48:08AM -0700, David Wolfskill wrote: [Ref. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=574034+0+current/cvs-all] ... eelf_i386.c:158: elf-hints.h: No such file or directory Crap,crap,crap,crap,crap!!! I thought I had gotten my systems clean enough when I did the post-commit ``make buildworld'' test. *sigh* a nice bootstrap issue here. Problem is elf-hints.h is a new header and a buildtool uses it. I guess a -I/usr/src/include is needed (or an install of headers into /usr/obj). To get over this hump if you aren't interested in debugging the bootstrap issue: cd /usr/src/include make obj make install -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/contrib/binutils/ld/emultempl elf32.em
In message [EMAIL PROTECTED] David O'Brien writes: : On Thu, May 03, 2001 at 07:48:08AM -0700, David Wolfskill wrote: : [Ref. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=574034+0+current/cvs-all] : ... : eelf_i386.c:158: elf-hints.h: No such file or directory : : Crap,crap,crap,crap,crap!!! : I thought I had gotten my systems clean enough when I did the post-commit : ``make buildworld'' test. *sigh* a nice bootstrap issue here. Problem : is elf-hints.h is a new header and a buildtool uses it. I guess a : -I/usr/src/include is needed (or an install of headers into /usr/obj). You would have to add -I/usr/include before the -I/usr/src/include. Otherwise things will compile with the host's stdio and friends, which could be bad if there were a mismatch between them (like in FILE definitions, say). Sometimes I think that adding a cross update install target which would put new .h files into /usr/obj/mumble/include might not be a bad thing : To get over this hump if you aren't interested in debugging the bootstrap : issue: : : cd /usr/src/include : make obj : make install This is kinda hard when compiling current on a stable system that you wish to remain stable system after the compile :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/contrib/binutils/ld/emultempl elf32.em
On Thu, 3 May 2001, Warner Losh wrote: In message [EMAIL PROTECTED] David O'Brien writes: ... : I thought I had gotten my systems clean enough when I did the post-commit : ``make buildworld'' test. *sigh* a nice bootstrap issue here. Problem : is elf-hints.h is a new header and a buildtool uses it. I guess a : -I/usr/src/include is needed (or an install of headers into /usr/obj). should be a relative path. Fixed in the committed version You would have to add -I/usr/include before the -I/usr/src/include. Otherwise things will compile with the host's stdio and friends, which could be bad if there were a mismatch between them (like in FILE definitions, say). The committed version has this bug. Sometimes I think that adding a cross update install target which would put new .h files into /usr/obj/mumble/include might not be a bad thing This has essentially the same problems as putting /usr/src/include before /usr/include. Very few headers outside of /usr/include are certain to work on the host for _all_ cross-tools. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
