Date: Sun, 21 Mar 2010 13:27:12 +0100 (CET) From: Alexander Best <alexbestms@wwu.de> To: Garrett Cooper <yanefbsd@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: build failures after stdlib update Message-ID: <permail-20100321122712f7e55a9d00006c06-a_best01@message-id.uni-muenster.de> In-Reply-To: <7d6fde3d1003210443j2879aca4lbd7187d9e41a5db2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Garrett Cooper schrieb am 2010-03-21: > On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best <alexbestms@wwu.de> > wrote: > > Garrett Cooper schrieb am 2010-03-21: > >> On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best > >> <alexbestms@wwu.de> > >> wrote: > >> > ok. i think i finally solved this riddle. the cause for the > >> > problem > >> > seems to > >> > have been my CPUTYPE in /etc/make.conf. it is set to 'native'. > >> > actually i've > >> > been using the 'native' keyword for years now and never had any > >> > problems with > >> > it, but it seems a recent commit broke 'native' as CPUTYPE. for > >> > me > >> > this is > >> > 100% reproducable: > >> > 1. put 'CPUTYPE = native' in /etc/make.conf > >> > 2. build and install gnu/usr.bin/cc > >> > 3. do 'buildkernel' or 'buildworld' and observe the segfault. > >> > for > >> > some reason > >> > this always occurs in lib/libc/string/strlen.c (r205108). i've > >> > tested this > >> > with older version of libc.so (built 22. Feb) and got the same > >> > result. so i > >> > assume this is not a libc problem, but a problem with gcc > >> > tripping > >> > over some > >> > code in libc. i have no clue however why this happend just now > >> > and > >> > not > >> > earlier. i don't think there has been a recent commit to gcc. > >> > to solve this there are two ways: > >> > 1. set CPUTYPE to 'nocona' (i'm running amd64). this will let > >> > you > >> > compile > >> > everything just fine even with a gcc that has itself been built > >> > with 'CPUTYPE > >> > = native'. > >> > 2. build and install gnu/usr.bin/cc with 'CPUTYPE = nocona'. the > >> > gcc version > >> > that has been built this way will compile everything just fine > >> > even > >> > with > >> > 'CPUTYPE = native'. the only way to break this is to go and > >> > compile > >> > gcc again > >> > with the CPUTYPE set to 'native'. > >> > so to summarize: compiling gnu/usr.bin/cc with CPUTYPE set to > >> > 'native' will > >> > give you a broken gcc! > >> What does -march=native yield in your case? There haven't been > >> any > >> recent commits to gcc, so I'm not sure whether or not that's the > >> issue. The libraries that I provided could have just been built > >> from > >> a > >> sane system -- maybe it's something else that needs to be explored > >> a > >> bit more closely to root cause the issue. > > i've experimented with setting CPUTYPE to native yesterday, but > > still couldn't > > figure out what the cause of it is. only a few points i'd like to > > point out: > > 1. this is very easily reproducible for me. i just need to set > > CPUTYPE=native > > in my /etc/make.conf and everything that gets linked against libc > > and uses the > > strlen() function won't compile due to gcc segfaulting. this is the > > case with > > /usr/src/bin/cat e.g. as well as kernel, world and probably lots of > > other > > stuff. > > also the following gcc command segfaults too (no need for setting > > CPUTYPE=native in this case, because -mtune gets set manually): > > gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 > > 2. there seems to be a connection with strlen.c because gcc alaways > > segfaults > > here. also i've been using CPUTYPE=native for years now and never > > had any > > problems with it. for me the segfault always happens in: > > #0 strlen (str=Variable "str" is not available. > > ) at /usr/src/lib/libc/string/strlen.c:100 > > 100 va = (*lp - mask01); > > it would be nice if people with arch i386 and amd64 could try to > > reproduce > > this (i believe the other archs don't support CPUTYPE=native). > > again the > > easiest way to trigger this (you don't need to edit your > > /etc/make.conf for > > this) should be running: > > gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 > > for now i'm using the attached patch to prevent myself from > > shooting me in the > > foot again. ;) > Works for me *shrugs*: > $ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1 > Using built-in specs. > Target: amd64-undermydesk-freebsd > Configured with: FreeBSD/amd64 system compiler > Thread model: posix > gcc version 4.2.1 20070719 [FreeBSD] > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null > -mtune=generic > ignoring duplicate directory "/usr/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/include > End of search list. > $ echo $? > 0 > Could you provide more specific details, i.e.: > 1. Hardware specs: > $ sysctl hw.machine hw.model hw.physmem > hw.machine: amd64 > hw.model: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz > hw.physmem: 12852424704 hw.machine: amd64 hw.model: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz hw.physmem: 2122203136 > 2. Do you have IA32 compatibility installed (now referred to as > FREEBSD_32)? yes. also i've attached by kernel conf, my make.conf and my src.conf. > Thanks, > -Garrett -- Alexander Best [-- Attachment #2 --] # WORLD/KERNEL options KERNCONF = ARUNDEL MODULES_OVERRIDE = \ netgraph/netgraph \ netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci \ netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt \ linux linprocfs linsysfs tmpfs \ usb/quirk fdescfs \ usb/uhid usb/ukbd usb/ums # GCC options .if !empty(.CURDIR:M/usr/ports/*) && exists(/usr/local/bin/gcc44) CC = gcc44 CXX = g++44 CPP = cpp44 .endif #CPUTYPE = native CPUTYPE = nocona COPTFLAGS= -O0 -pipe -fno-builtin CFLAGS = -O2 -fno-strict-aliasing -pipe -fno-builtin CXXFLAGS += -fconserve-space DEBUG_FLAGS = -g # SENDMAIL options SENDMAIL_MC = /etc/mail/freebsd.mc SENDMAIL_SUBMIT_MC = /etc/mail/freebsd.submit.mc # PORTS options OVERRIDE_LINUX_BASE_PORT = f10 OVERRIDE_LINUX_NONBASE_PORTS = f10 DA4 = yes #WITH_BSDEL = yes #WITH_256_COLOR = yes # MISC options DOC_LANG = en_US.ISO8859-1 de_DE.ISO8859-15 # added by use.perl 2010-02-20 14:58:13 PERL_VERSION = 5.10.1 [-- Attachment #3 --] # BUILDWORLD options WITHOUT_ACCT=true WITHOUT_AMD=true WITHOUT_APM=true WITHOUT_ATM=true WITHOUT_AUDIT=true WITHOUT_BIND=true WITHOUT_BSNMP=true WITHOUT_CDDL=true WITHOUT_CTM=true WITHOUT_CVS=true WITHOUT_FLOPPY=true WITHOUT_FREEBSD_UPDATE=true WITHOUT_GAMES=true WITHOUT_GPIB=true WITH_IDEA=true WITHOUT_INET6=true WITHOUT_IPFILTER=true WITHOUT_IPFW=true WITHOUT_IPX=true WITHOUT_JAIL=true WITHOUT_LPR=true WITHOUT_MAILWRAPPER=true WITHOUT_NCP=true WITHOUT_NDIS=true WITHOUT_NETCAT=true WITHOUT_NIS=true WITHOUT_NLS=true WITHOUT_NLS_CATALOGS=true WITHOUT_NS_CACHING=true WITHOUT_PAM=true WITHOUT_PF=true WITHOUT_PROFILE=true WITHOUT_PPP=true WITHOUT_QUOTAS=true WITHOUT_RCMDS=true WITHOUT_RCS=true WITHOUT_ROUTED=true WITHOUT_SLIP=true WITHOUT_SYSINSTALL=true WITHOUT_TCSH=true WITHOUT_TELNET=true # CLANG options WITH_CLANG= WITH_CLANG_IS_CC= NO_WERROR= WERROR= # Don't forget this when using Jails! NO_FSCHG=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?permail-20100321122712f7e55a9d00006c06-a_best01>