Re: Buildworld Fails RELENG_7
On May 19, Dave Uhring reported the following kind of RELENG_7 buildworld failure: /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c -o eng_openssl.So /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c -o eng_padlock.So /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c: In function 'padlock_xcrypt_ecb': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c:445: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c:445: error: 'asm' operand has impossible constraints On May 20, Doug Rabson gave a hint: 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? With today's RELENG_7 I spotted a similar kind of compilation problem, and this gave a hint to solving it. In my case, the problem was that I had set the following environment variables (for enabling the compilation of a program): LDFLAGS=-L/usr/local/lib CFLAGS= (or CFLAGS=-pg, not 100% sure) unsetenv'ing these fixed by 'make buildworld'. I wonder if this is something that the build scripts themselves should catch and correct? -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
Dave Uhring wrote: 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. This part is behaving as expected for FreeBSD; the make process coverts any of the athlon64 cpu types into athlon-mp. Based on the gcc documentation I don't think it makes much difference; the only discrepancy between the two seems the presence of the 64-bit instruction set. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
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.) -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Tue, May 20, 2008 at 09:24:11AM -0500, Dave Uhring wrote:
> 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.
So? This is normal.
Look at /usr/share/mk/bsd.cpu.mk. I see this code:
. elif ${CPUTYPE} == "opteron" || ${CPUTYPE} == "athlon64" || ${CPUTYPE} ==
"k8"
CPUTYPE = athlon-mp
There's your answer for that.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On 20 May 2008, at 14:31, Dave Uhring wrote: 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. Excellent. Thanks for your help tracking this down. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
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. 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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Tue, May 20, 2008 at 01:33:15PM +1000, Mark Andrews wrote:
>
> And when tested does behave the way you describe.
>
> Mark
>
> drugs:9.5.x 13:30 {4371} % bash
> [EMAIL PROTECTED] ~/cvs/9.5.x]$ printenv | grep FOO
> [EMAIL PROTECTED] ~/cvs/9.5.x]$ FOO=ll
> [EMAIL PROTECTED] ~/cvs/9.5.x]$ export FOO
> [EMAIL PROTECTED] ~/cvs/9.5.x]$ printenv | grep FOO
> FOO=ll
> [EMAIL PROTECTED] ~/cvs/9.5.x]$ FOO=""
> [EMAIL PROTECTED] ~/cvs/9.5.x]$ export FOO
> [EMAIL PROTECTED] ~/cvs/9.5.x]$ printenv | grep FOO
> FOO=
> [EMAIL PROTECTED] ~/cvs/9.5.x]$ env -i PATH=$PATH printenv | grep FOO
> [EMAIL PROTECTED] ~/cvs/9.5.x]$
This is Solaris but bash is bash:
[EMAIL PROTECTED] ~]$ printenv | grep CFLAGS
CFLAGS=-xO3 -m32 -xarch=native -mt -I/usr/sfw/include -I/usr/X11/include
-I/opt/sfw/include
You have mail in /var/mail/duhring
[EMAIL PROTECTED] ~]$ export CFLAGS=""
[EMAIL PROTECTED] ~]$ printenv | grep CFLAGS
CFLAGS=
[EMAIL PROTECTED] ~]$ export CFLAGS='-xO3 -m32 -xarch=native'
[EMAIL PROTECTED] ~]$ printenv | grep CFLAGS
CFLAGS=-xO3 -m32 -xarch=native
[EMAIL PROTECTED] ~]$ export CFLAGS=""
[EMAIL PROTECTED] ~]$ printenv | grep CFLAGS
CFLAGS=
[EMAIL PROTECTED] ~]$ env -i PATH=$PATH printenv | grep CFLAGS
[EMAIL PROTECTED] ~]$
When I tell you that CFLAGS="", CFLAGS="", and a cursory
examination of my last compiler output would have shown you exactly
that.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On 20 May 2008, at 01:02, Dave Uhring wrote: On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote: On May 19, 2008, at 1:21 PM, Dave Uhring wrote: In any case, that problem has been solved by putting the updated header files in /usr/include/sys and will be properly fixed when I can finally make installworld. I did not have to manually move or copy any header files. *default release=cvs tag=RELENG_7 My build on that, csupped just after seeing your first message in this thread, has just completed. make buildworld worked just fine without error. I'm also on athlon64. All the headers that I needed were in the right places in /usr/src Did you start from a RELEASE source tree and userland? So all I can say is that things worked for me. I really suspect that you got /usr/src and /usr/obj into some sort of inconsistent state. I completely removed both, cvsupped a new RELENG_7 source tree, removed /etc/make.conf and got this: /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c -o eng_openssl.So /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c -o eng_padlock.So /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c: In function 'padlock_xcrypt_ecb': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c:445: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c:445: error: 'asm' operand has impossible constraints 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? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On 2008-May-19 21:51:30 -0500, Dave Uhring <[EMAIL PROTECTED]> wrote: >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. As Mark pointed out, this just means bash is broken. Note that the FreeBSD build toolset is designed to work with sh - if you've managed to convince make to use bash, you may have run into an incompatibility that is causing your buildworld failures. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpLkdSQK0MwM.pgp Description: PGP signature
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 07:02:36PM -0500, Dave Uhring wrote: > On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote: > > On May 19, 2008, at 1:21 PM, Dave Uhring wrote: > > > >> In any case, that problem has been solved by putting the updated header > >> files > >> in /usr/include/sys and will be properly fixed when I can finally make > >> installworld. > > > > I did not have to manually move or copy any header files. > > > >> *default release=cvs tag=RELENG_7 > > > > My build on that, csupped just after seeing your first message in this > > thread, has just completed. make buildworld worked just fine without > > error. I'm also on athlon64. All the headers that I needed were in the > > right places in /usr/src > > Did you start from a RELEASE source tree and userland? > > > So all I can say is that things worked for me. I really suspect that you > > got /usr/src and /usr/obj into some sort of inconsistent state. > > I completely removed both, cvsupped a new RELENG_7 source tree, removed > /etc/make.conf and got this: > If I were you I would suspect hardware problems. In particular bad memory - that is often the reason behind the kind of wierd errors you have been seeing. (Suspect number two would be overheating of some component.) In your place I would run memtest86 (for several full passes) to check the memory. > /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE > -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl > -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto > -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN > -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c > -o eng_openssl.So > /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE > -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl > -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto > -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN > -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c > -o eng_padlock.So > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c: > In function 'padlock_xcrypt_ecb': > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c:445: > error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' > /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c:445: > error: 'asm' operand has impossible constraints > *** Error code 1 > > Stop in /usr/src/secure/lib/libcrypto. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > real 8m58.524s > user 7m18.995s > sys 1m22.150s > > Solaris Nevada b_87 is installing on the server this minute instead of > FreeBSD. > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 12:16:46PM -0700, Jeremy Chadwick wrote: > I will attempt the same with your make.conf to see if it's any > different. I'll add that while I slept, I let a 'make buildworld' go with your exact make.conf flags -- it completed successfully. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 03:03:42PM -0500, Dave Uhring wrote: > [EMAIL PROTECTED] /usr/src/contrib/groff]# mount > /dev/ad4s2a on / (ufs, local, soft-updates) > devfs on /dev (devfs, local) > /dev/ad4s2h on /home (ufs, local, soft-updates) > /dev/ad4s2e on /usr (ufs, local, soft-updates) > /dev/ad4s2g on /usr/local (ufs, local, soft-updates) > /dev/ad4s2d on /var (ufs, local, soft-updates) > /dev/md0 on /tmp (ufs, local, soft-updates) > /dev/ad4s2f on /usr/obj (ufs, asynchronous, local, noatime) > [EMAIL PROTECTED] /usr/src/contrib/groff]# > > Not even an NFS mount. I'm trying to update to FreeBSD-STABLE to use on my > home file server. At present it has OpenSolaris installed but that OS does > not have the Ethernet driver I need and I want to be able to use 2 Adaptec > 29160N HBAs in the system. But I only have 2 PCI slots and I would like to > remove the Intel NIC and use the system's on-board nfe NIC. > > I'll blow away /usr/src and /usr/obj, cvsup the entire RELENG_7 source tree > again and once more attempt to buildworld. If that fails, Solaris stays on > the server. And please be sure to nuke /var/db/sup/src-all (or /usr/sup/src-all if you're using cvsup for some reason). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:10:32PM -0400, Josh Carroll wrote: > > No, even though it is a dual-core system. I did not want to chance a > > race condition. I simply executed 'make buildworld' initially, then > > 'make -DNO_CLEAN buildworld' when I encountered problems in the build. > > Ok, it was worth asking, just to rule out the obvious. > > I'm still not sure where your logic in using -DNOCLEAN comes in, for a > failed build. I would expect that to continue to fail in most > circumstances if it were already failing. If you fix what caused the build to break and want to find any other failure points there is little point in restarting the build from zero. > So I think in one of your other mails you said you're installing > something else now? Solaris? If so, this thread is moot, since you > aren't running FreeBSD on the box anymore, and no one has been able to > reproduce your problem. I think the most likely culprits have already > been mentioned in the thread so far anyway. I would still like to get FreeBSD on that server but with the latest improvements to ZFS. The release version is not going to do that for me and the only way that I can get up-to-date binaries is to build a new world and kernel. I'll give it another days' try and if that still fails Solaris will stay on the server. This BTW is not my first time building world on FreeBSD. I followed STABLE from 3.4 through the end of RELENG_4 and I never had such problems with a simple compile. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
>
> > 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
And when tested does behave the way you describe.
Mark
drugs:9.5.x 13:30 {4371} % bash
[EMAIL PROTECTED] ~/cvs/9.5.x]$ printenv | grep FOO
[EMAIL PROTECTED] ~/cvs/9.5.x]$ FOO=ll
[EMAIL PROTECTED] ~/cvs/9.5.x]$ export FOO
[EMAIL PROTECTED] ~/cvs/9.5.x]$ printenv | grep FOO
FOO=ll
[EMAIL PROTECTED] ~/cvs/9.5.x]$ FOO=""
[EMAIL PROTECTED] ~/cvs/9.5.x]$ export FOO
[EMAIL PROTECTED] ~/cvs/9.5.x]$ printenv | grep FOO
FOO=
[EMAIL PROTECTED] ~/cvs/9.5.x]$ env -i PATH=$PATH printenv | grep FOO
[EMAIL PROTECTED] ~/cvs/9.5.x]$
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 10:59:18PM -0400, Josh Carroll wrote: > > 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. > > I think what Mark was getting at is that simply setting CFLAGS to "" > prior to make does not trump the setting of CFLAGS in > make.conf/src.conf. So if you haven't removed/commented that from > your make.conf, the export command above will do nothing for the > actual build environment. Before that last build I had removed /etc/make.conf and had never touched src.conf. CFLAGS was empty. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
> 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: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
> No, even though it is a dual-core system. I did not want to chance a > race condition. I simply executed 'make buildworld' initially, then > 'make -DNO_CLEAN buildworld' when I encountered problems in the build. Ok, it was worth asking, just to rule out the obvious. I'm still not sure where your logic in using -DNOCLEAN comes in, for a failed build. I would expect that to continue to fail in most circumstances if it were already failing. So I think in one of your other mails you said you're installing something else now? Solaris? If so, this thread is moot, since you aren't running FreeBSD on the box anymore, and no one has been able to reproduce your problem. I think the most likely culprits have already been mentioned in the thread so far anyway. Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 10:08:22PM -0400, Josh Carroll wrote: > > The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 > > new header files that I placed from cvsupped sources into /usr/include/sys > > the entire system is 7.0 RELEASE. > > > > Prior to beginning the build I deliberately set > > > > # export CFLAGS="" > > > > Nothing else in my environment would have affected the compiler. > > You're not using make -j when building world are you? If so, remove > that and see if it then builds properly. No, even though it is a dual-core system. I did not want to chance a race condition. I simply executed 'make buildworld' initially, then 'make -DNO_CLEAN buildworld' when I encountered problems in the build. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
> 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. I think what Mark was getting at is that simply setting CFLAGS to "" prior to make does not trump the setting of CFLAGS in make.conf/src.conf. So if you haven't removed/commented that from your make.conf, the export command above will do nothing for the actual build environment. Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
> The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 > new header files that I placed from cvsupped sources into /usr/include/sys > the entire system is 7.0 RELEASE. > > Prior to beginning the build I deliberately set > > # export CFLAGS="" > > Nothing else in my environment would have affected the compiler. You're not using make -j when building world are you? If so, remove that and see if it then builds properly. Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
Dave Uhring wrote: On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote: On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: The problem is that gcc is *not* finding the file in the directory referenced by the -I cflag. If I copy the header files to the directory where the error occurs the header file is found and used to compile the source file. This starts to narrow down the problem you're having a bit, I think. Given that this is different from the expected behavior and the behavior others are seeing, this sounds to me like either 1) the wrong compiler or version of the compiler is being found and used in place of the desired gcc instance, or 2) something in your shell or environment is somehow getting into the buildworld environment and causing make or the inner shell to misparse the commandline to gcc. The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 new header files that I placed from cvsupped sources into /usr/include/sys the entire system is 7.0 RELEASE. Prior to beginning the build I deliberately set # export CFLAGS="" Nothing else in my environment would have affected the compiler I suspect there is still *something* affecting your compiler, though where from I couldn't even guess. According to this message: http://gcc.gnu.org/ml/gcc-help/2007-04/msg00200.html the most recent error you posted, from inside OpenSSL, only happens if you compile the library at -O0, which is definitely not the default behavior. If you've already blown away your FreeBSD environment there's obviously not much more you can do to track down the problem, but it would be interesting to know what: make -V CFLAGS actually returned from within /usr/src. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
> On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote: > > On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: > > > > > > The problem is that gcc is *not* finding the file in the directory > > > referenced by the -I cflag. If I copy the header files to the directory > > > where the error occurs the header file is found and used to compile the > > > source file. > > > > This starts to narrow down the problem you're having a bit, I think. > > > > Given that this is different from the expected behavior and the > > behavior others are seeing, this sounds to me like either 1) the wrong > > compiler or version of the compiler is being found and used in place of > > the desired gcc instance, or 2) something in your shell or environment > > is somehow getting into the buildworld environment and causing make or > > the inner shell to misparse the commandline to gcc. > > The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 > new header files that I placed from cvsupped sources into /usr/include/sys > the entire system is 7.0 RELEASE. > > Prior to beginning the build I deliberately set > > # export CFLAGS="" This does NOT remove CFLAGS from the environment. env -i PATH=$PATH make ... will clear the enviornment and just add PATH. e.g. % env -i PATH="$PATH" SHELL="$SHELL" HOME="$HOME" printenv PATH=/home/marka/gnu/bin:/home/marka/bin/mask:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/bin:/usr/X11R6/bin:/home/marka/bin:/usr/local/sbin SHELL=/bin/csh HOME=/home/marka % > Nothing else in my environment would have affected the compiler. > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 02:01:48PM -1000, Clifton Royston wrote: > On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: > > > > The problem is that gcc is *not* finding the file in the directory > > referenced by the -I cflag. If I copy the header files to the directory > > where the error occurs the header file is found and used to compile the > > source file. > > This starts to narrow down the problem you're having a bit, I think. > > Given that this is different from the expected behavior and the > behavior others are seeing, this sounds to me like either 1) the wrong > compiler or version of the compiler is being found and used in place of > the desired gcc instance, or 2) something in your shell or environment > is somehow getting into the buildworld environment and causing make or > the inner shell to misparse the commandline to gcc. The c compiler is the one shipped with 7.0 RELEASE. Except for the 3 new header files that I placed from cvsupped sources into /usr/include/sys the entire system is 7.0 RELEASE. Prior to beginning the build I deliberately set # export CFLAGS="" Nothing else in my environment would have affected the compiler. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On May 19, 2008, at 7:02 PM, Dave Uhring wrote: On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote: I did not have to manually move or copy any header files. Did you start from a RELEASE source tree and userland? No. I was upgrading from STABLE last built about on April 29. However near the beginning of April I did move from RELEASE to STABLE. So several builds ago, I had moved from RELEASE to STABLE. So all I can say is that things worked for me. I really suspect that you got /usr/src and /usr/obj into some sort of inconsistent state. I completely removed both, cvsupped a new RELENG_7 source tree, removed /etc/make.conf and got this: /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c -o eng_openssl.So /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c -o eng_padlock.So /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c: In function 'padlock_xcrypt_ecb': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c:445: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c:445: error: 'asm' operand has impossible constraints *** Error code 1 Stop in /usr/src/secure/lib/libcrypto. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. real8m58.524s user7m18.995s sys 1m22.150s I have no idea of what the problem may be. I'm hoping that someone more knowledgeable will be able to help. What is interesting here is that this latest error does not appear to be the result of missing header files. Best of luck with this, -j ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On 2008-May-19 11:38:25 -0500, Dave Uhring <[EMAIL PROTECTED]> wrote: >Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a >clean >build. You have this backwards. If you are getting wierd buildworld errors, your first step should be to delete /usr/obj and then run 'make clean'. My guess is that you have some cruft in your /usr/src. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpU4xKEcmIrh.pgp Description: PGP signature
Re: Buildworld Fails RELENG_7
On May 19, 2008, at 1:21 PM, Dave Uhring wrote: In any case, that problem has been solved by putting the updated header files in /usr/include/sys and will be properly fixed when I can finally make installworld. I did not have to manually move or copy any header files. *default release=cvs tag=RELENG_7 My build on that, csupped just after seeing your first message in this thread, has just completed. make buildworld worked just fine without error. I'm also on athlon64. All the headers that I needed were in the right places in /usr/src So all I can say is that things worked for me. I really suspect that you got /usr/src and /usr/obj into some sort of inconsistent state. Cheers, -j -- Jeffrey Goldberghttp://www.goldmark.org/jeff/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 06:46:41PM -0500, Jeffrey Goldberg wrote: > On May 19, 2008, at 1:21 PM, Dave Uhring wrote: > >> In any case, that problem has been solved by putting the updated header >> files >> in /usr/include/sys and will be properly fixed when I can finally make >> installworld. > > I did not have to manually move or copy any header files. > >> *default release=cvs tag=RELENG_7 > > My build on that, csupped just after seeing your first message in this > thread, has just completed. make buildworld worked just fine without > error. I'm also on athlon64. All the headers that I needed were in the > right places in /usr/src Did you start from a RELEASE source tree and userland? > So all I can say is that things worked for me. I really suspect that you > got /usr/src and /usr/obj into some sort of inconsistent state. I completely removed both, cvsupped a new RELENG_7 source tree, removed /etc/make.conf and got this: /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c -o eng_openssl.So /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c -o eng_padlock.So /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c: In function 'padlock_xcrypt_ecb': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c:445: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c:445: error: 'asm' operand has impossible constraints *** Error code 1 Stop in /usr/src/secure/lib/libcrypto. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. real8m58.524s user7m18.995s sys 1m22.150s Solaris Nevada b_87 is installing on the server this minute instead of FreeBSD. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 03:14:08PM -0500, Dave Uhring wrote: > On Mon, May 19, 2008 at 02:54:31PM -0400, Lowell Gilbert wrote: > > Dave Uhring <[EMAIL PROTECTED]> writes: > > > > > > If a -I/some/directory is used as a CFLAG then the *include directive > > > must read > > > > > > #include , *not* #include "driver.h". The latter demands that > > > the > > > header file be in the same directory as the source file. > > > > Not that it necessarily affects what you're going through, but that > > last statement is incorrect. The double quotes are (according to the > > C standard) implementation defined, and gcc (like many other > > compilers) will prefer the local directory for the double quotes, but > > will search the entire search path if it doesn't find the file there. > > The problem is that gcc is *not* finding the file in the directory > referenced by the -I cflag. If I copy the header files to the directory > where the error occurs the header file is found and used to compile the > source file. This starts to narrow down the problem you're having a bit, I think. Given that this is different from the expected behavior and the behavior others are seeing, this sounds to me like either 1) the wrong compiler or version of the compiler is being found and used in place of the desired gcc instance, or 2) something in your shell or environment is somehow getting into the buildworld environment and causing make or the inner shell to misparse the commandline to gcc. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 02:54:31PM -0400, Lowell Gilbert wrote: > Dave Uhring <[EMAIL PROTECTED]> writes: > > > > If a -I/some/directory is used as a CFLAG then the *include directive must > > read > > > > #include , *not* #include "driver.h". The latter demands that the > > header file be in the same directory as the source file. > > Not that it necessarily affects what you're going through, but that > last statement is incorrect. The double quotes are (according to the > C standard) implementation defined, and gcc (like many other > compilers) will prefer the local directory for the double quotes, but > will search the entire search path if it doesn't find the file there. The problem is that gcc is *not* finding the file in the directory referenced by the -I cflag. If I copy the header files to the directory where the error occurs the header file is found and used to compile the source file. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 12:16:46PM -0700, Jeremy Chadwick wrote: > On Mon, May 19, 2008 at 11:00:28AM -0700, Jeremy Chadwick wrote: > > This picked up src-all using the RELENG_7 tag. I then attempted a > > buildworld (cd /usr/src && time make -j2 buildworld). It's just begun > > stage 2.3, but so far no issues. I'll report back in about 30 minutes > > or so, when it has a chance to finish. That is what I did after the first build using the original RELEASE sources and updated using csup. I blew away /usr/src and cvsupped a fresh RELENG_7 source tree. > The compile has finished successfully. Took 1 hour 15 minutes. Another > user also mailed me (privately) adding that he too cannot reproduce this > problem. Last time I succeeded in building world on another box it took 47 minutes :-) That's still a long way from years back when RELENG_4 built in 30 minutes on a machine with an Athlon Tbird 1.2GHz processor. Double the processor speed and quadruple the memory and the build takes 50% longer. > I will attempt the same with your make.conf to see if it's any > different. But at this point, it appears the issue is with your system > or system configuration. I just wish I knew what was doing it. Any odd > filesystem mount flags (output of "mount")? [EMAIL PROTECTED] /usr/src/contrib/groff]# mount /dev/ad4s2a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/ad4s2h on /home (ufs, local, soft-updates) /dev/ad4s2e on /usr (ufs, local, soft-updates) /dev/ad4s2g on /usr/local (ufs, local, soft-updates) /dev/ad4s2d on /var (ufs, local, soft-updates) /dev/md0 on /tmp (ufs, local, soft-updates) /dev/ad4s2f on /usr/obj (ufs, asynchronous, local, noatime) [EMAIL PROTECTED] /usr/src/contrib/groff]# Not even an NFS mount. I'm trying to update to FreeBSD-STABLE to use on my home file server. At present it has OpenSolaris installed but that OS does not have the Ethernet driver I need and I want to be able to use 2 Adaptec 29160N HBAs in the system. But I only have 2 PCI slots and I would like to remove the Intel NIC and use the system's on-board nfe NIC. I'll blow away /usr/src and /usr/obj, cvsup the entire RELENG_7 source tree again and once more attempt to buildworld. If that fails, Solaris stays on the server. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
Dave Uhring wrote: If a -I/some/directory is used as a CFLAG then the *include directive must read #include , *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." ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:00:28AM -0700, Jeremy Chadwick wrote: > This picked up src-all using the RELENG_7 tag. I then attempted a > buildworld (cd /usr/src && time make -j2 buildworld). It's just begun > stage 2.3, but so far no issues. I'll report back in about 30 minutes > or so, when it has a chance to finish. The compile has finished successfully. Took 1 hour 15 minutes. Another user also mailed me (privately) adding that he too cannot reproduce this problem. I will attempt the same with your make.conf to see if it's any different. But at this point, it appears the issue is with your system or system configuration. I just wish I knew what was doing it. Any odd filesystem mount flags (output of "mount")? -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
Dave Uhring <[EMAIL PROTECTED]> writes: > 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 , *not* #include "driver.h". The latter demands that the > header file be in the same directory as the source file. Not that it necessarily affects what you're going through, but that last statement is incorrect. The double quotes are (according to the C standard) implementation defined, and gcc (like many other compilers) will prefer the local directory for the double quotes, but will search the entire search path if it doesn't find the file there. It also has some really wacky command-line parameters to control which directories are searched (by *both* #include syntaxes) down to a ridiculously fine level. The only use I've ever had for such things was in cross-compile environments targeting multiple architectures in a single build tree, and even then it isn't really necessary. - Lowell -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
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 , *not* #include "driver.h". The latter demands that the header file be in the same directory as the source file. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:00:28AM -0700, Jeremy Chadwick wrote: > > Something I thought of while doing the above: there's been reports in > the past of problems with buildworld (or building software in general) > bombing out or behaving oddly due to clock issues on the local machine. > If you don't use ntpd, consider doing so. Otherwise, at least use > ntpdate once to set your clock to something sane. I hadn't yet started ntpd but [EMAIL PROTECTED] /etc]# ntpdate newton 19 May 13:29:22 ntpdate[55524]: step time server 192.168.0.8 offset -1.044724 sec I doubt that a second off would make any difference. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 06:00:39PM +0100, Doug Rabson wrote: > > The thing is that a working buildworld doesn't depend on headers from > /usr/include. One of the first thing it does is install a set of new > headers in somewhere like /usr/obj/usr/src/tmp. At this point, it might be > useful to see a log of a failed buildworld attempt to see what is going > wrong. Putting the updated header files in /usr/include/sys solved that problem. Whether is was the correct solution or not is moot since the build continued from the previous stoppage in libc. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 10:04:28AM -0700, Jeremy Chadwick wrote: > On Mon, May 19, 2008 at 11:58:07AM -0500, Dave Uhring wrote: > > > > I have repeately nuked /usr/obj. That is not going to put updated header > > files > > where they need to be. > > It's apparent you don't quite understand. The "updated header files" > reside in /usr/src, and ***remain there*** until installworld is done. That is as it should be. > The buildworld process will include the "updated header files", trumping > most of those which are in /usr/include. Does not happen. The header files included were those from /usr/include/sys, not /usr/src/sys/sys. The errors would not have occurred if the header files in /usr/src/sys/sys were being referenced by In any case, that problem has been solved by putting the updated header files in /usr/include/sys and will be properly fixed when I can finally make installworld. > > Remember I'm starting from a RELEASE userland. This is just about as bad as > > jumping from one full release to the next :( > > Okay, so you installed 7.0-RELEASE on a machine. Did you choose to > install src from the CD/DVD when installing? (If so, you will need to > "adopt" the version you installed to the current version, see the cvsup > FAQ here: http://www.cvsup.org/faq.html#caniadopt -- and you'll need to > do this for ports if you installed the ports tree off the CD/DVD as > well) > > If you csup'd, what tag did you use? RELENG_7? I'm assuming so. Did > you use src-all, or are you using a custom supfile? We use > /usr/share/examples/cvsup/stable-supfile. Whatever tag was in /usr/share/examples/cvsup/stable-supfile. In fact it is: *default release=cvs tag=RELENG_7 > -- > | Jeremy Chadwickjdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 10:06:19AM -0700, Jeremy Chadwick wrote: > Give me a few hours (installing VMware + 7.0-RELEASE + csup). My money > is on that I won't be able to reproduce the problem. Something I thought of while doing the above: there's been reports in the past of problems with buildworld (or building software in general) bombing out or behaving oddly due to clock issues on the local machine. If you don't use ntpd, consider doing so. Otherwise, at least use ntpdate once to set your clock to something sane. Anyway. I've completed the above using VMware. Installation was 7.0-RELEASE i386. fdisk and label were defaults, and for distributions I chose base, kernels, dict, doc, games, info, man, and catman. (I do not pick src and ports because I don't care to deal with the "adoption" method.) I also configured the network (nothing out of the ordinary; pure DHCP), and the time zone (PDT). Immediately after the system was up, I did the following: # csup -h cvsup4.freebsd.org -g -L 2 -4 /usr/share/examples/cvsup/stable-supfile This picked up src-all using the RELENG_7 tag. I then attempted a buildworld (cd /usr/src && time make -j2 buildworld). It's just begun stage 2.3, but so far no issues. I'll report back in about 30 minutes or so, when it has a chance to finish. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
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: [EMAIL PROTECTED] /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" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 10:06:19AM -0700, Jeremy Chadwick wrote: > On Mon, May 19, 2008 at 12:03:34PM -0500, Dave Uhring wrote: > > > > [EMAIL PROTECTED] /etc]$ grep -v ^# make.conf > > CPUTYPE?=athlon64 > > 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 > > Can you please comment out all of the above and see if the problem > persists? Sure, but that is not going to put the correct headers where the sources are looking for them. Nor is it going to put groff headers into a directory where the #include "driver.h" is declared within a source file and the directory contains *no* headers. In particular, /usr/src/contrib/groff/src/libs/libdriver has no header files at all, yet input.cpp in that directory has these declarations: #include "driver.h" #include "device.h" > > Start with a clean RELEASE userland and try to build RELENG_7 today :) > > Give me a few hours (installing VMware + 7.0-RELEASE + csup). My money > is on that I won't be able to reproduce the problem. VMware? Give me a break! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 12:03:34PM -0500, Dave Uhring wrote: > On Mon, May 19, 2008 at 09:59:25AM -0700, Jeremy Chadwick wrote: > > > > Is there breakage of some sort being caused by your make.conf or (less > > probable) your src.conf? Any filesystem corruption (boot single user > > and force fsck on all the filesystems)? > > [EMAIL PROTECTED] /etc]$ grep -v ^# make.conf > CPUTYPE?=athlon64 > 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 Can you please comment out all of the above and see if the problem persists? > > In all the years I've used FreeBSD, I've never had to copy include files > > from parts of /usr/src to get buildworld to work, so this is very odd > > behaviour. > > Start with a clean RELEASE userland and try to build RELENG_7 today :) Give me a few hours (installing VMware + 7.0-RELEASE + csup). My money is on that I won't be able to reproduce the problem. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:58:07AM -0500, Dave Uhring wrote: > On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote: > > > > Is there some reason you're using -DNO_CLEAN, and haven't just nuked > > /usr/obj/* and done buildworld normally? I can't reproduce any of this > > behaviour on any of our RELENG_7 systems. > > I have repeately nuked /usr/obj. That is not going to put updated header > files > where they need to be. It's apparent you don't quite understand. The "updated header files" reside in /usr/src, and ***remain there*** until installworld is done. The buildworld process will include the "updated header files", trumping most of those which are in /usr/include. You do not need to copy any files from /usr/src/sys/sys to /usr/include or anywhere else to get buildworld to work. If you're having to do that, the problem is very likely elsewhere. > I'm using -DNO_CLEAN in order to get the system to a point where a build just > might succeed without -DNO_CLEAN and I'm not getting there without some header > files being in the right place. > > Remember I'm starting from a RELEASE userland. This is just about as bad as > jumping from one full release to the next :( Okay, so you installed 7.0-RELEASE on a machine. Did you choose to install src from the CD/DVD when installing? (If so, you will need to "adopt" the version you installed to the current version, see the cvsup FAQ here: http://www.cvsup.org/faq.html#caniadopt -- and you'll need to do this for ports if you installed the ports tree off the CD/DVD as well) If you csup'd, what tag did you use? RELENG_7? I'm assuming so. Did you use src-all, or are you using a custom supfile? We use /usr/share/examples/cvsup/stable-supfile. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 09:59:25AM -0700, Jeremy Chadwick wrote: > > Is there breakage of some sort being caused by your make.conf or (less > probable) your src.conf? Any filesystem corruption (boot single user > and force fsck on all the filesystems)? [EMAIL PROTECTED] /etc]$ grep -v ^# make.conf CPUTYPE?=athlon64 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 src.conf is untouched. > In all the years I've used FreeBSD, I've never had to copy include files > from parts of /usr/src to get buildworld to work, so this is very odd > behaviour. Start with a clean RELEASE userland and try to build RELENG_7 today :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On 19 May 2008, at 17:58, Dave Uhring wrote: On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote: Is there some reason you're using -DNO_CLEAN, and haven't just nuked /usr/obj/* and done buildworld normally? I can't reproduce any of this behaviour on any of our RELENG_7 systems. I have repeately nuked /usr/obj. That is not going to put updated header files where they need to be. I'm using -DNO_CLEAN in order to get the system to a point where a build just might succeed without -DNO_CLEAN and I'm not getting there without some header files being in the right place. Remember I'm starting from a RELEASE userland. This is just about as bad as jumping from one full release to the next :( The thing is that a working buildworld doesn't depend on headers from / usr/include. One of the first thing it does is install a set of new headers in somewhere like /usr/obj/usr/src/tmp. At this point, it might be useful to see a log of a failed buildworld attempt to see what is going wrong. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:54:21AM -0500, Dave Uhring wrote: > On Mon, May 19, 2008 at 05:42:56PM +0100, Doug Rabson wrote: > > > > On 19 May 2008, at 17:38, Dave Uhring wrote: > > > >> On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: > >>> 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'? > >> > >> Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get > >> a clean > >> build. > >> > >> The header files in /usr/include/sys are those from 7.0 RELEASE, however, > >> and I > >> have had to copy 3 files (so far) from /usr/src/sys/sys to get the build > >> to > >> continue. > > > > You should never have to copy any header files to /usr/include to get a > > buildworld to work. Try without the -DNO_CLEAN and if that still fails, > > clean your /usr/obj (e.g. with rm -rf /usr/obj/*). > > The build is going nowhere without the correct header files in > /usr/include/sys. Is there breakage of some sort being caused by your make.conf or (less probable) your src.conf? Any filesystem corruption (boot single user and force fsck on all the filesystems)? In all the years I've used FreeBSD, I've never had to copy include files from parts of /usr/src to get buildworld to work, so this is very odd behaviour. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 09:42:21AM -0700, Jeremy Chadwick wrote: > > Is there some reason you're using -DNO_CLEAN, and haven't just nuked > /usr/obj/* and done buildworld normally? I can't reproduce any of this > behaviour on any of our RELENG_7 systems. I have repeately nuked /usr/obj. That is not going to put updated header files where they need to be. I'm using -DNO_CLEAN in order to get the system to a point where a build just might succeed without -DNO_CLEAN and I'm not getting there without some header files being in the right place. Remember I'm starting from a RELEASE userland. This is just about as bad as jumping from one full release to the next :( ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 05:42:56PM +0100, Doug Rabson wrote: > > On 19 May 2008, at 17:38, Dave Uhring wrote: > >> On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: >>> 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'? >> >> Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get >> a clean >> build. >> >> The header files in /usr/include/sys are those from 7.0 RELEASE, however, >> and I >> have had to copy 3 files (so far) from /usr/src/sys/sys to get the build >> to >> continue. > > You should never have to copy any header files to /usr/include to get a > buildworld to work. Try without the -DNO_CLEAN and if that still fails, > clean your /usr/obj (e.g. with rm -rf /usr/obj/*). The build is going nowhere without the correct header files in /usr/include/sys. I have repeatedly cleaned /usr/obj to no avail, but I have a better method for doing that: umount /usr/obj newfs /dev/da4s2f mount /usr/obj ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On 19 May 2008, at 17:38, Dave Uhring wrote: On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: 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'? Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a clean build. The header files in /usr/include/sys are those from 7.0 RELEASE, however, and I have had to copy 3 files (so far) from /usr/src/sys/sys to get the build to continue. You should never have to copy any header files to /usr/include to get a buildworld to work. Try without the -DNO_CLEAN and if that still fails, clean your /usr/obj (e.g. with rm -rf /usr/obj/*). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 11:38:25AM -0500, Dave Uhring wrote: > On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: > > 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'? > > Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a > clean > build. > > The header files in /usr/include/sys are those from 7.0 RELEASE, however, and > I > have had to copy 3 files (so far) from /usr/src/sys/sys to get the build to > continue. > > [EMAIL PROTECTED] /usr/include/sys]# ls *.orig > fcntl.h.orig tree.h.orig umtx.h.orig > > Just got another stoppage in /usr/src/gnu/lib/libstdc++. > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: > error: unwind.h: No such file or directory > > The #include declaration has that header file in the local directory. It > exists in > /usr/obj, however. Is there some reason you're using -DNO_CLEAN, and haven't just nuked /usr/obj/* and done buildworld normally? I can't reproduce any of this behaviour on any of our RELENG_7 systems. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
On Mon, May 19, 2008 at 05:07:08PM +0100, Doug Rabson wrote: > 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'? Yes, although at this point is it 'make -DNO_CLEAN buildworld' until I get a clean build. The header files in /usr/include/sys are those from 7.0 RELEASE, however, and I have had to copy 3 files (so far) from /usr/src/sys/sys to get the build to continue. [EMAIL PROTECTED] /usr/include/sys]# ls *.orig fcntl.h.orig tree.h.orig umtx.h.orig Just got another stoppage in /usr/src/gnu/lib/libstdc++. /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: error: unwind.h: No such file or directory The #include declaration has that header file in the local directory. It exists in /usr/obj, however. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Buildworld Fails RELENG_7
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 "[EMAIL PROTECTED] " ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
