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
This is a MIME encoded multipart message. --+permail-20100321122712f7e55a9d00006c06-a_best01+ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 =3D native' in /etc/make.conf > >> > 2. build and install gnu/usr.bin/cc > >> > 3. do 'buildkernel' or 'buildworld' and observe the segfault. > >> > for > >> > =A0 =A0some 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 > >> > =A0 =A0compile > >> > everything just fine even with a gcc that has itself been built > >> > with 'CPUTYPE > >> > =3D native'. > >> > 2. build and install gnu/usr.bin/cc with 'CPUTYPE =3D nocona'. the > >> > =A0 =A0gcc version > >> > that has been built this way will compile everything just fine > >> > even > >> > with > >> > 'CPUTYPE =3D 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! > >> =A0 =A0 What does -march=3Dnative yield in your case? There haven't be= en > >> =A0 =A0 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=3Dnative > > 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=3Dnative in this case, because -mtune gets set manually): > > gcc -v -x c -E -mtune=3Dnative /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=3Dnative for years now and never > > had any > > problems with it. for me the segfault always happens in: > > #0 =A0strlen (str=3DVariable "str" is not available. > > ) at /usr/src/lib/libc/string/strlen.c:100 > > 100 =A0 =A0 =A0 =A0 =A0 =A0 va =3D (*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=3Dnative). > > 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=3Dnative /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=3Dnative /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=3Dgeneric > 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 --=20 Alexander Best --+permail-20100321122712f7e55a9d00006c06-a_best01+ Content-Type: application/octet-stream Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="make.conf" IyBXT1JMRC9LRVJORUwgb3B0aW9ucwpLRVJOQ09ORiA9IEFSVU5ERUwKTU9EVUxFU19PVkVSUklE RSA9IFwKbmV0Z3JhcGgvbmV0Z3JhcGggXApuZXRncmFwaC9zb2NrZXQgbmV0Z3JhcGgvYmx1ZXRv b3RoL2JsdWV0b290aCBuZXRncmFwaC9ibHVldG9vdGgvaGNpIFwKbmV0Z3JhcGgvYmx1ZXRvb3Ro L2wyY2FwIG5ldGdyYXBoL2JsdWV0b290aC9zb2NrZXQgbmV0Z3JhcGgvYmx1ZXRvb3RoL3VidCBc CmxpbnV4IGxpbnByb2NmcyBsaW5zeXNmcyB0bXBmcyBcCnVzYi9xdWlyayBmZGVzY2ZzIFwKdXNi L3VoaWQgdXNiL3VrYmQgdXNiL3VtcwoKIyBHQ0Mgb3B0aW9ucwouaWYgIWVtcHR5KC5DVVJESVI6 TS91c3IvcG9ydHMvKikgJiYgZXhpc3RzKC91c3IvbG9jYWwvYmluL2djYzQ0KQpDQyA9ICBnY2M0 NApDWFggPSBnKys0NApDUFAgPSBjcHA0NAouZW5kaWYKCiNDUFVUWVBFID0gbmF0aXZlCkNQVVRZ UEUgPSBub2NvbmEKQ09QVEZMQUdTPSAtTzAgLXBpcGUgLWZuby1idWlsdGluCkNGTEFHUyA9IC1P MiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZSAtZm5vLWJ1aWx0aW4KQ1hYRkxBR1MgKz0gLWZj b25zZXJ2ZS1zcGFjZQpERUJVR19GTEFHUyA9IC1nCgojIFNFTkRNQUlMIG9wdGlvbnMKU0VORE1B SUxfTUMgPSAvZXRjL21haWwvZnJlZWJzZC5tYwpTRU5ETUFJTF9TVUJNSVRfTUMgPSAvZXRjL21h aWwvZnJlZWJzZC5zdWJtaXQubWMKCiMgUE9SVFMgb3B0aW9ucwpPVkVSUklERV9MSU5VWF9CQVNF X1BPUlQgPSBmMTAKT1ZFUlJJREVfTElOVVhfTk9OQkFTRV9QT1JUUyA9IGYxMApEQTQgPSB5ZXMK I1dJVEhfQlNERUwgPSB5ZXMKI1dJVEhfMjU2X0NPTE9SID0geWVzCgojIE1JU0Mgb3B0aW9ucwpE T0NfTEFORyA9IGVuX1VTLklTTzg4NTktMSBkZV9ERS5JU084ODU5LTE1CgojIGFkZGVkIGJ5IHVz ZS5wZXJsIDIwMTAtMDItMjAgMTQ6NTg6MTMKUEVSTF9WRVJTSU9OID0gNS4xMC4xCg== --+permail-20100321122712f7e55a9d00006c06-a_best01+ Content-Type: application/octet-stream Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="src.conf" IyBCVUlMRFdPUkxEIG9wdGlvbnMKV0lUSE9VVF9BQ0NUPXRydWUKV0lUSE9VVF9BTUQ9dHJ1ZQpX SVRIT1VUX0FQTT10cnVlCldJVEhPVVRfQVRNPXRydWUKV0lUSE9VVF9BVURJVD10cnVlCldJVEhP VVRfQklORD10cnVlCldJVEhPVVRfQlNOTVA9dHJ1ZQpXSVRIT1VUX0NEREw9dHJ1ZQpXSVRIT1VU X0NUTT10cnVlCldJVEhPVVRfQ1ZTPXRydWUKV0lUSE9VVF9GTE9QUFk9dHJ1ZQpXSVRIT1VUX0ZS RUVCU0RfVVBEQVRFPXRydWUKV0lUSE9VVF9HQU1FUz10cnVlCldJVEhPVVRfR1BJQj10cnVlCldJ VEhfSURFQT10cnVlCldJVEhPVVRfSU5FVDY9dHJ1ZQpXSVRIT1VUX0lQRklMVEVSPXRydWUKV0lU SE9VVF9JUEZXPXRydWUKV0lUSE9VVF9JUFg9dHJ1ZQpXSVRIT1VUX0pBSUw9dHJ1ZQpXSVRIT1VU X0xQUj10cnVlCldJVEhPVVRfTUFJTFdSQVBQRVI9dHJ1ZQpXSVRIT1VUX05DUD10cnVlCldJVEhP VVRfTkRJUz10cnVlCldJVEhPVVRfTkVUQ0FUPXRydWUKV0lUSE9VVF9OSVM9dHJ1ZQpXSVRIT1VU X05MUz10cnVlCldJVEhPVVRfTkxTX0NBVEFMT0dTPXRydWUKV0lUSE9VVF9OU19DQUNISU5HPXRy dWUKV0lUSE9VVF9QQU09dHJ1ZQpXSVRIT1VUX1BGPXRydWUKV0lUSE9VVF9QUk9GSUxFPXRydWUK V0lUSE9VVF9QUFA9dHJ1ZQpXSVRIT1VUX1FVT1RBUz10cnVlCldJVEhPVVRfUkNNRFM9dHJ1ZQpX SVRIT1VUX1JDUz10cnVlCldJVEhPVVRfUk9VVEVEPXRydWUKV0lUSE9VVF9TTElQPXRydWUKV0lU SE9VVF9TWVNJTlNUQUxMPXRydWUKV0lUSE9VVF9UQ1NIPXRydWUKV0lUSE9VVF9URUxORVQ9dHJ1 ZQoKIyBDTEFORyBvcHRpb25zCldJVEhfQ0xBTkc9CldJVEhfQ0xBTkdfSVNfQ0M9Ck5PX1dFUlJP Uj0KV0VSUk9SPQojIERvbid0IGZvcmdldCB0aGlzIHdoZW4gdXNpbmcgSmFpbHMhCk5PX0ZTQ0hH PQo= --+permail-20100321122712f7e55a9d00006c06-a_best01+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?permail-20100321122712f7e55a9d00006c06-a_best01>