| From | Sent On | Attachments |
|---|---|---|
| Pegasus Mc Cleaft | Mar 13, 2010 10:30 am | |
| Garrett Cooper | Mar 13, 2010 12:49 pm | |
| Pegasus Mc Cleaft | Mar 13, 2010 4:33 pm | |
| Alexander Best | Mar 16, 2010 4:15 am | |
| Peter Jeremy | Mar 16, 2010 12:37 pm | |
| Alexander Best | Mar 16, 2010 7:22 pm | |
| Pegasus Mc Cleaft | Mar 16, 2010 7:29 pm | |
| Pegasus Mc Cleaft | Mar 17, 2010 9:53 am | |
| Alexander Best | Mar 20, 2010 3:21 pm | |
| Alexander Best | Mar 20, 2010 5:54 pm | |
| Andriy Gapon | Mar 20, 2010 7:27 pm | |
| Garrett Cooper | Mar 20, 2010 9:47 pm | |
| Alexander Best | Mar 21, 2010 3:59 am | .txt |
| Garrett Cooper | Mar 21, 2010 4:42 am | |
| Andriy Gapon | Mar 21, 2010 5:01 am | |
| Alexander Best | Mar 21, 2010 5:26 am | .conf, .conf |
| Pegasus Mc Cleaft | Mar 21, 2010 5:32 am | |
| Alexander Best | Mar 21, 2010 5:35 am | .txt |
| Alexander Best | Mar 21, 2010 5:43 am | |
| Andriy Gapon | Mar 21, 2010 5:50 am | |
| Alexander Best | Mar 21, 2010 5:53 am | |
| Gary Jennejohn | Mar 21, 2010 6:02 am | |
| Gary Jennejohn | Mar 21, 2010 6:07 am | |
| Andriy Gapon | Mar 21, 2010 8:10 am | |
| Dimitry Andric | Mar 21, 2010 8:34 am | |
| Alexander Best | Mar 21, 2010 11:45 am | |
| Andriy Gapon | Mar 21, 2010 1:28 pm | |
| Alexander Best | Mar 21, 2010 2:10 pm | |
| Garrett Cooper | Mar 21, 2010 2:19 pm | .log |
| Garrett Cooper | Mar 21, 2010 2:20 pm | |
| Garrett Cooper | Mar 21, 2010 2:23 pm | |
| Andriy Gapon | Mar 21, 2010 2:31 pm | |
| Alexander Best | Mar 21, 2010 3:11 pm | |
| jhell | Mar 21, 2010 5:28 pm | |
| Dimitry Andric | Mar 22, 2010 12:54 am | |
| Andriy Gapon | Mar 22, 2010 1:07 am | |
| Alexander Best | Mar 22, 2010 2:39 am | |
| Scot Hetzel | Mar 22, 2010 7:57 pm | |
| Alexander Best | Mar 23, 2010 2:33 am | |
| Pegasus Mc Cleaft | Mar 23, 2010 2:59 am | |
| Alexander Best | Mar 23, 2010 3:40 am | .txt, .txt |
| Scot Hetzel | Mar 23, 2010 11:19 am | |
| Garrett Cooper | Mar 23, 2010 12:07 pm | |
| Alexander Best | Mar 23, 2010 3:35 pm | |
| jhell | Mar 23, 2010 4:48 pm | |
| Xin LI | Mar 23, 2010 5:05 pm |
| Subject: | Re: build failures after stdlib update | |
|---|---|---|
| From: | Garrett Cooper (yane...@gmail.com) | |
| Date: | Mar 21, 2010 4:42:52 am | |
| List: | org.freebsd.freebsd-current | |
On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best <alex...@wwu.de> wrote:
Garrett Cooper schrieb am 2010-03-21:
On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best <alex...@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
2. Do you have IA32 compatibility installed (now referred to as FREEBSD_32)?
Thanks, -Garrett
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "free...@freebsd.org"






.txt