Sources checked out yesterday, updated this morning using cvsup and repository at cvsup12.freebsd.org. The build fails in /usr/src/lib/libc /usr/bin/gcc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/sys/fcntl.c /usr/src/lib/libc/sys/fcntl.c: In function 'fcntl': /usr/src/lib/libc/sys/fcntl.c:42: error: storage size of 'ofl' isn't known /usr/src/lib/libc/sys/fcntl.c:67: error: 'F_OGETLK' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:67: error: (Each undeclared identifier is reported only once /usr/src/lib/libc/sys/fcntl.c:67: error: for each function it appears in.) /usr/src/lib/libc/sys/fcntl.c:74: error: 'struct flock' has no member named 'l_sysid' /usr/src/lib/libc/sys/fcntl.c:79: error: 'F_OSETLK' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:82: error: 'F_OSETLKW' undeclared (first use in this function) /usr/src/lib/libc/sys/fcntl.c:42: warning: unused variable 'ofl' *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1
This symbol has been added to fcntl.h recently. It appears as if your build is picking up the installed header rather than the one from the source tree. Are you using 'make buildworld'? On 19 May 2008, at 16:17, Dave Uhring wrote:> Sources checked out yesterday, updated this morning using cvsup and > repository at cvsup12.freebsd.org. The build fails in /usr/src/lib/ > libc > > /usr/bin/gcc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -I/ > usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/ > src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../ > contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/ > libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES - > DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING - > DSYMBOL_VERSIONING -Wsystem-headers -Wall -Wno-format-y2k -Wno- > uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/sys/fcntl.c > /usr/src/lib/libc/sys/fcntl.c: In function 'fcntl': > /usr/src/lib/libc/sys/fcntl.c:42: error: storage size of 'ofl' isn't > known > /usr/src/lib/libc/sys/fcntl.c:67: error: 'F_OGETLK' undeclared > (first use in this function) > /usr/src/lib/libc/sys/fcntl.c:67: error: (Each undeclared identifier > is reported only once > /usr/src/lib/libc/sys/fcntl.c:67: error: for each function it > appears in.) > /usr/src/lib/libc/sys/fcntl.c:74: error: 'struct flock' has no > member named 'l_sysid' > /usr/src/lib/libc/sys/fcntl.c:79: error: 'F_OSETLK' undeclared > (first use in this function) > /usr/src/lib/libc/sys/fcntl.c:82: error: 'F_OSETLKW' undeclared > (first use in this function) > /usr/src/lib/libc/sys/fcntl.c:42: warning: unused variable 'ofl' > *** Error code 1 > > Stop in /usr/src/lib/libc. > *** Error code 1 > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > "
On Mon, May 19, 2008 at 10:02:23AM -0700, David Wolfskill wrote:> On Mon, May 19, 2008 at 11:54:21AM -0500, Dave Uhring wrote: > > > > The build is going nowhere without the correct header files in /usr/include/sys. > > That appears to indicate that your build environment is fundamentally > broken.. > > You might consider doing the build within script(1), then making the > resulting script file available for folks to examine.I posted the relevant output from "make buildworld". Copying the 3 new header files from /usr/src/sys/sys to /usr/include/sys solved my original problem. I'm sure that after a successful buildworld and installworld that the original problem will go away. The problem now is in the build of groff: [root@maxwell /usr/src/contrib/groff/src/devices/grodvi]# ls *.h ls: *.h: No such file or directory However, dvi.cpp in that directory has this: #include "driver.h" #include "nonposix.h" #include "paper.h"
On Mon, May 19, 2008 at 11:02:01AM -0700, David Wolfskill wrote:> On Mon, May 19, 2008 at 12:53:58PM -0500, Dave Uhring wrote: > > > > I posted the relevant output from "make buildworld". Copying the 3 new header > > files from /usr/src/sys/sys to /usr/include/sys solved my original problem. > > s/solved/circumvented/:) Whatever, libc does build now.> freebeast(8.0-C)[52] ls -l usr/src/contrib/groff/src/devices/grodvi/*.h > ls: No match. > freebeast(8.0-C)[53] grep '#include "' usr/src/contrib/groff/src/devices/grodvi/dvi.cpp > #include "driver.h" > #include "nonposix.h" > #include "paper.h" > freebeast(8.0-C)[54] > > The compilation of dvi.cpp uses > "-I/usr/src/gnu/usr.bin/groff/src/devices/grodvi/../../../../../../contrib/groff/src/include > -I/usr/src/gnu/usr.bin/groff/src/devices/grodvi/../../../src/include" > (among other things); I expect you will find the needed header files > in those directories.If a -I/some/directory is used as a CFLAG then the *include directive must read #include <driver.h>, *not* #include "driver.h". The latter demands that the header file be in the same directory as the source file.
Dave Uhring wrote:> If a -I/some/directory is used as a CFLAG then the *include directive must read > > #include <driver.h>, *not* #include "driver.h". The latter demands that the > header file be in the same directory as the source file.Absolutely not true. Directly from the gcc online manual: "GCC looks for headers requested with #include "file" first in the directory containing the current file, then in the directories as specified by -iquote options, then in the same places it would have looked for a header requested with angle brackets. For example, if /usr/include/sys/stat.h contains #include "types.h", GCC looks for types.h first in /usr/include/sys, then in its usual search path."
> On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: > > > > > # export CFLAGS="" > > > > This does NOT remove CFLAGS from the environment. > > It does when you shell is bash.bash is broken. Empty environment variables have meaning. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
> > > On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote: > > > > > > > # export CFLAGS="" > > > > > > This does NOT remove CFLAGS from the environment. > > > > It does when you shell is bash. > > bash is broken. Empty environment variables have meaning. > > MarkAnd when tested does behave the way you describe. Mark drugs:9.5.x 13:30 {4371} % bash [marka@drugs ~/cvs/9.5.x]$ printenv | grep FOO [marka@drugs ~/cvs/9.5.x]$ FOO=ll [marka@drugs ~/cvs/9.5.x]$ export FOO [marka@drugs ~/cvs/9.5.x]$ printenv | grep FOO FOO=ll [marka@drugs ~/cvs/9.5.x]$ FOO="" [marka@drugs ~/cvs/9.5.x]$ export FOO [marka@drugs ~/cvs/9.5.x]$ printenv | grep FOO FOO[marka@drugs ~/cvs/9.5.x]$ env -i PATH=$PATH printenv | grep FOO [marka@drugs ~/cvs/9.5.x]$> -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Tue, May 20, 2008 at 12:54:59PM +0100, Doug Rabson wrote:> > On 20 May 2008, at 12:25, Dave Uhring wrote: > >> On Tue, May 20, 2008 at 08:50:14AM +0100, Doug Rabson wrote: >>> >>> In this, your build is explicitly using '/usr/bin/gcc' for the build >>> which >>> is not the way buildworld normally works. In normal operation, buildworld >>> first builds a compiler from source and then uses that compiler by adding >>> to $PATH and building with just 'cc'. Are you overriding $CC in your >>> environment? >> >> I did not even have $CC in my environment. My environment had absolutely >> nothing involving the compiler and the compiler was the one shipped with >> FreeBSD-7.0-RELEASE. It is the *only* compiler on the system. >> > > Odd. Could you please send me the complete log of a failed build attempt.I did not maintain such a log. On that last build everything proceeded normally until it broke in an inline assembler piece of code. But I published not only the error but also the previous 4 or 5 compile lines. I'm building again with a virgin clean cvsupped source tree from cvsup4.freebsd.org, a clean /usr/obj, and I have reverted to /bin/csh for my root shell if that can possibly matter. /etc/make.conf sets the build shell as /bin/sh. This time I started the build using script. The entire log will be available.
Tried again this morning with a fresh cvsup from cvsup4.freebsd.org and the build went to completion. maxwell# grep -v ^# /etc/make.conf CPUTYPE?=k8 CFLAGS= -O2 -fno-strict-aliasing -pipe -m32 CXXFLAGS+= -fconserve-space MAKE_SHELL?=sh COPTFLAGS= -O -pipe INSTALL=install -C MTREE_FOLLOWS_SYMLINKS= -L ENABLE_SUID_SSHNO_SENDMAILNO_PROFILEDOC_LANG= en_US.ISO8859-1 maxwell# printenv MACHTYPE=i386 USER=root MAIL=/var/mail/root SHLVL=2 VENDOR=intel HOME=/root PAGER=more GROUP=wheel LOGNAME=root TERM=xterm BLOCKSIZE=K WINDOWPATH=9 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin REMOTEHOSTDISPLAY=:0.0 XAUTHORITY=/root/.Xauthority HOST=maxwell.uhring.com SHELL=/bin/csh OSTYPE=FreeBSD PWD=/root FTP_PASSIVE_MODE=YES HOSTTYPE=FreeBSD EDITOR=vi WINDOWID=14680077 XTERM_VERSION=XTerm(235) XTERM_LOCALE=C TERMCAP=xterm|xterm-color|X11 terminal emulator:ti@:te@:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:kH=\EOF:@7=\EOF:kI=\E[2~:kh=\EOH:*6=\EOF:kP=\E[5~:kN=\E[6~:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:Km=\E[M:li#24:co#80:am:kn#12:km:mi:ms:xn:AX:bl=^G:is=\E[!p\E[?3;4l\E[4l\E>:rs=\E[!p\E[?3;4l\E[4l\E>:le=^H:AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:al=\E[L:dc=\E[P:dl=\E[M:UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:ho=\E[H:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l:ks=\E[?1h\E=:ke=\E[?1l\E>:kD=\E[3~:sf=\n:sr=\EM:st=\EH:ct=\E[3g:sc=\E7:rc=\E8:eA=\E(B\E)0:as=\E(0:ae=\E(B:ml=\El:mu=\Em:up=\E[A:nd=\E[C:md=\E[1m:me=\E[m:mr=\E[7m:so=\E[7m:se=\E[27m:us=\E[4m:ue=\E[24m:vi=\E[?25l:ve=\E[?25h:ut:Co#8:pa#64:op=\E[39;49m:AB=\E[4%dm:AF=\E[3%dm:kb=\010: XTERM_SHELL=/bin/csh Note the last line. Even if /etc/make.conf specifies the build shell, that is apparently ignored in the build process. The CPUTYPE in /etc/make.conf is also ignored and make chooses one from thin air apparently since the cflags used in the build are shown in the last line of the compile: cc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -DTM_GMTOFF=tm_gmtoff -DTM_ZONE=tm_zone -DSTD_INSPIRED -DPCTS -DHAVE_LONG_DOUBLE -DTZDIR=\"/usr/share/zoneinfo\" -Demkdir=mkdir -I/usr/src/usr.sbin/zic/zdump/.. -I/usr/src/usr.sbin/zic/zdump/../../../lib/libc/stdtime -o zdump zdump.o ialloc.o scheck.o I specified CPUTYPE?=k8 but make chose -march=athlon-mp. Thanks to all who tried to help.
On Tue, May 20, 2008 at 09:24:11AM -0500, Dave Uhring wrote:> Tried again this morning with a fresh cvsup from cvsup4.freebsd.org and the > build went to completion. > > maxwell# grep -v ^# /etc/make.conf > CPUTYPE?=k8 > CFLAGS= -O2 -fno-strict-aliasing -pipe -m32 > CXXFLAGS+= -fconserve-space > MAKE_SHELL?=sh > COPTFLAGS= -O -pipe > INSTALL=install -C > MTREE_FOLLOWS_SYMLINKS= -L > ENABLE_SUID_SSH> NO_SENDMAIL> NO_PROFILE> DOC_LANG= en_US.ISO8859-1 > > maxwell# printenv > MACHTYPE=i386 > USER=root > MAIL=/var/mail/root > SHLVL=2 > VENDOR=intel > HOME=/root > PAGER=more > GROUP=wheel > LOGNAME=root > TERM=xterm > BLOCKSIZE=K > WINDOWPATH=9 > PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > REMOTEHOST> DISPLAY=:0.0 > XAUTHORITY=/root/.Xauthority > HOST=maxwell.uhring.com > SHELL=/bin/csh > OSTYPE=FreeBSD > PWD=/root > FTP_PASSIVE_MODE=YES > HOSTTYPE=FreeBSD > EDITOR=vi > WINDOWID=14680077 > XTERM_VERSION=XTerm(235) > XTERM_LOCALE=C > TERMCAP=xterm|xterm-color|X11 terminal emulator:ti@:te@:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:kH=\EOF:@7=\EOF:kI=\E[2~:kh=\EOH:*6=\EOF:kP=\E[5~:kN=\E[6~:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:Km=\E[M:li#24:co#80:am:kn#12:km:mi:ms:xn:AX:bl=^G:is=\E[!p\E[?3;4l\E[4l\E>:rs=\E[!p\E[?3;4l\E[4l\E>:le=^H:AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:al=\E[L:dc=\E[P:dl=\E[M:UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:ho=\E[H:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l:ks=\E[?1h\E=:ke=\E[?1l\E>:kD=\E[3~:sf=\n:sr=\EM:st=\EH:ct=\E[3g:sc=\E7:rc=\E8:eA=\E(B\E)0:as=\E(0:ae=\E(B:ml=\El:mu=\Em:up=\E[A:nd=\E[C:md=\E[1m:me=\E[m:mr=\E[7m:so=\E[7m:se=\E[27m:us=\E[4m:ue=\E[24m:vi=\E[?25l:ve=\E[?25h:ut:Co#8:pa#64:op=\E[39;49m:AB=\E[4%dm:AF=\E[3%dm:kb=\010: > XTERM_SHELL=/bin/csh > > Note the last line. Even if /etc/make.conf specifies the build shell, that > is apparently ignored in the build process.I do not think the build process cares even slightly which shell is used for xterm.> > The CPUTYPE in /etc/make.conf is also ignored and make chooses one from thin > air apparently since the cflags used in the build are shown in the last line > of the compile: > > cc -O2 -fno-strict-aliasing -pipe -m32 -march=athlon-mp -DTM_GMTOFF=tm_gmtoff -DTM_ZONE=tm_zone -DSTD_INSPIRED -DPCTS -DHAVE_LONG_DOUBLE -DTZDIR=\"/usr/share/zoneinfo\" -Demkdir=mkdir -I/usr/src/usr.sbin/zic/zdump/.. -I/usr/src/usr.sbin/zic/zdump/../../../lib/libc/stdtime -o zdump zdump.o ialloc.o scheck.o > > I specified CPUTYPE?=k8 but make chose -march=athlon-mp.Yes, it is supposed to do that. It used to be the case that gcc did not have any specific -march or -mcpu flags or optimizations for the K8 architecture, so the make system chooses -march=athlon-mp since that is the closest architecture that can be specified. (Look in /usr/share/mk/bsd.cpu.mk too see how it chooses -march flags based on your setting of CPUTYPE.) I am fairly certain however that gcc 4.x does know about the K8 CPUs these days, so somebody should probably go through bsd.cpu.mk and update it for the latest gcc (at least for -CURRENT.) -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se