Re: build failures after stdlib update
i don't think conf/112997 and the issue where gcc segfaults are directly related to each other: 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune | sed -e 's/.*mtune=//'` to determine gcc's idea of the appropriate -mtune value. that command however segfaults. so this doesn't really help. 2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=native` examples. for me `make` prints the same no matter what CPUTYPE is set to: otaku% make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=nocona amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=i386 amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala amd64 sse2 sse ..oh and of course i ran these commands with no CPUTYPE set in make.conf. ;) -- Alexander Best ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
Pegasus Mc Cleaft schrieb am 2010-03-23: -Original Message- 2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=native` examples. for me `make` prints the same no matter what CPUTYPE is set to: otaku% make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=nocona amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=i386 amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala amd64 sse2 sse ..oh and of course i ran these commands with no CPUTYPE set in make.conf. ;) This is interesting. I tried the same thing on my computer (AMD64 - Core2 Quad) and I get the following (Without CPUTYPE?=native in /etc/make) feathers$ make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse (With CPUTYPE?=native) feathers$ make -V MACHINE_CPU -DCPUTYPE=native unknown amd64 sse2 sse mmx (For both) feathers$ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null -mtune=generic hmm...that's odd indeed. i finally was able to do some debugging. i've attached two files: running gcc -v -x c -E -mtune=native /dev/null and gcc -v -x c -E -mtune=nocona /dev/null Peg -- Alexander Best `gdb -v -x c -E -mtune=native /dev/null`: Breakpoint 26, strlen (str=0x7fffed6e /dev/null) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); (gdb) Continuing. Breakpoint 26, strlen (str=0x7fffed73 null) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); (gdb) Continuing. Breakpoint 26, strlen (str=0x43e04a include) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); (gdb) Continuing. Breakpoint 26, strlen (str=0x458a30 ) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); (gdb) Continuing. Breakpoint 26, strlen (str=0x458a30 ) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); (gdb) Continuing. Breakpoint 26, strlen (str=0x43e5eb -m) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); (gdb) Continuing. Breakpoint 26, strlen (str=0x80a2d8 Error reading address 0x80a2d8: Bad address) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); `gdb -v -x c -E -mtune=nocona /dev/null`: Breakpoint 1, strlen (str=0x7fffed73 null) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); (gdb) Continuing. Breakpoint 1, strlen (str=0x43e04a include) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); (gdb) Continuing. Breakpoint 1, strlen (str=0x458a30 ) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); (gdb) Continuing. Breakpoint 1, strlen (str=0x458a30 ) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); (gdb) Continuing. Breakpoint 1, strlen (str=0x7fffed56 v) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); (gdb) Continuing. Breakpoint 1, strlen (str=0x7fffed5e E) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); (gdb) Continuing. Breakpoint 1, strlen (str=0x7fffed61 mtune=nocona) at /usr/src/lib/libc/string/strlen.c:99 99 lp = (const unsigned long *)((uintptr_t)str ~LONGPTR_MASK); ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best alexbes...@wwu.de wrote: i don't think conf/112997 and the issue where gcc segfaults are directly related to each other: 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune | sed -e 's/.*mtune=//'` to determine gcc's idea of the appropriate -mtune value. that command however segfaults. so this doesn't really help. The command runs correctly with a properly built gcc: # gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune | sed -e 's/.*mtune=//' generic 2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=native` examples. for me `make` prints the same no matter what CPUTYPE is set to: otaku% make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=nocona amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=i386 amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala amd64 sse2 sse ..oh and of course i ran these commands with no CPUTYPE set in make.conf. ;) If I run the same commands as above, I get similar results: # make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=k8 amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=nocona amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=i386 amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=lala amd64 sse2 sse But if I run the commands without the -D, it shows the problem correctly: # make -V MACHINE_CPU CPUTYPE=native unknown amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=k8 k8 3dnow amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=nocona sse3 amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=i386 unknown amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=lalala unknown amd64 sse2 sse mmx # grep CPUTYPE /etc/make.conf /etc/src.conf grep: /etc/src.conf: No such file or directory This was run under a Feb 28th -CURRENT. Now here is something strange. Defining CPUTYPE in /etc/src.conf has no effect on the output of MACHING_CPU. /etc/src.conf: 1 lines, 11 characters. # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf amd64 sse2 sse /etc/src.conf:CPUTYPE=k8 # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf k8 3dnow amd64 sse2 sse mmx /etc/make.conf:CPUTYPE=k8 Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Tue, Mar 23, 2010 at 11:19 AM, Scot Hetzel swhet...@gmail.com wrote: On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best alexbes...@wwu.de wrote: i don't think conf/112997 and the issue where gcc segfaults are directly related to each other: 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune | sed -e 's/.*mtune=//'` to determine gcc's idea of the appropriate -mtune value. that command however segfaults. so this doesn't really help. The command runs correctly with a properly built gcc: # gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune | sed -e 's/.*mtune=//' generic 2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=native` examples. for me `make` prints the same no matter what CPUTYPE is set to: otaku% make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=nocona amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=i386 amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala amd64 sse2 sse ..oh and of course i ran these commands with no CPUTYPE set in make.conf. ;) If I run the same commands as above, I get similar results: # make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=k8 amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=nocona amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=i386 amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=lala amd64 sse2 sse But if I run the commands without the -D, it shows the problem correctly: # make -V MACHINE_CPU CPUTYPE=native unknown amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=k8 k8 3dnow amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=nocona sse3 amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=i386 unknown amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=lalala unknown amd64 sse2 sse mmx # grep CPUTYPE /etc/make.conf /etc/src.conf grep: /etc/src.conf: No such file or directory This was run under a Feb 28th -CURRENT. Now here is something strange. Defining CPUTYPE in /etc/src.conf has no effect on the output of MACHING_CPU. /etc/src.conf: 1 lines, 11 characters. # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf amd64 sse2 sse /etc/src.conf:CPUTYPE=k8 # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf k8 3dnow amd64 sse2 sse mmx /etc/make.conf:CPUTYPE=k8 CPUTYPE can and should be defined in make.conf; it has been this way since the beginning of time (tongue in cheek). src.conf gets sourced in bsd.own.mk and make.conf gets sourced in sys.mk. I'll leave it to you to trace down which gets called first and in what order the logic gets evaluated, but I'm pretty sure it's doing the wrong thing when you put CPUTYPE in src.conf. The other thing to keep in mind is that -VCPUTYPE and -DCPUTYPE are evaluated differently: -D variable Define variable to be 1, in the global context. ... -V variable Print make's idea of the value of variable, in the global con- text. Do not build any targets. Multiple instances of this option may be specified; the variables will be printed one per line, with a blank line for each null or undefined variable. So I think that the example code is probably incorrect for -D ;). Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
Scot Hetzel schrieb am 2010-03-23: On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best alexbes...@wwu.de wrote: i don't think conf/112997 and the issue where gcc segfaults are directly related to each other: 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune | sed -e 's/.*mtune=//'` to determine gcc's idea of the appropriate -mtune value. that command however segfaults. so this doesn't really help. The command runs correctly with a properly built gcc: # gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune | sed -e 's/.*mtune=//' generic i was finally able to solve this issue. it turns out the issue was caused by an option in my CLFAGS called -fno-builtin. sys/conf/NOTES recommends using this switch for kernel builds, but it seems in a world environment the flag is harmful to gcc. a gcc built with -fno-builtin trips over strlen() for some reason. you should be able to reproduce this problem simply by adding -O2 -fno-strict-aliasing -pipe -fno-builtin to your CFLAGS. maybe -O2 -fno-builtin triggers it too, but -fno-builtin (without -O2) doesn't. thanks to everyone for all the help. :) cheers. alex 2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=native` examples. for me `make` prints the same no matter what CPUTYPE is set to: otaku% make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=nocona amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=i386 amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala amd64 sse2 sse ..oh and of course i ran these commands with no CPUTYPE set in make.conf. ;) If I run the same commands as above, I get similar results: # make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=k8 amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=nocona amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=i386 amd64 sse2 sse # make -V MACHINE_CPU -DCPUTYPE=lala amd64 sse2 sse But if I run the commands without the -D, it shows the problem correctly: # make -V MACHINE_CPU CPUTYPE=native unknown amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=k8 k8 3dnow amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=nocona sse3 amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=i386 unknown amd64 sse2 sse mmx # make -V MACHINE_CPU CPUTYPE=lalala unknown amd64 sse2 sse mmx # grep CPUTYPE /etc/make.conf /etc/src.conf grep: /etc/src.conf: No such file or directory This was run under a Feb 28th -CURRENT. Now here is something strange. Defining CPUTYPE in /etc/src.conf has no effect on the output of MACHING_CPU. /etc/src.conf: 1 lines, 11 characters. # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf amd64 sse2 sse /etc/src.conf:CPUTYPE=k8 # make -V MACHINE_CPU ; grep CPUTYPE /etc/make.conf /etc/src.conf k8 3dnow amd64 sse2 sse mmx /etc/make.conf:CPUTYPE=k8 Scot -- Alexander Best ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Tue, 23 Mar 2010 06:40, alexbestms@ wrote: Pegasus Mc Cleaft schrieb am 2010-03-23: -Original Message- 2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=native` examples. for me `make` prints the same no matter what CPUTYPE is set to: otaku% make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=nocona amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=i386 amd64 sse2 sse otaku% make -V MACHINE_CPU -DCPUTYPE=lalalala amd64 sse2 sse ..oh and of course i ran these commands with no CPUTYPE set in make.conf. ;) This is interesting. I tried the same thing on my computer (AMD64 - Core2 Quad) and I get the following (Without CPUTYPE?=native in /etc/make) feathers$ make -V MACHINE_CPU -DCPUTYPE=native amd64 sse2 sse (With CPUTYPE?=native) feathers$ make -V MACHINE_CPU -DCPUTYPE=native unknown amd64 sse2 sse mmx (For both) feathers$ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune /usr/libexec/cc1 -E -quiet -v -D_LONGLONG /dev/null -o /dev/null -mtune=generic hmm...that's odd indeed. i finally was able to do some debugging. i've attached two files: running gcc -v -x c -E -mtune=native /dev/null and gcc -v -x c -E -mtune=nocona /dev/null Peg Both the commands that your showing the output of in the attached output are using gdb when the options that were presented are for gcc. `gdb -v -x c -E -mtune=native /dev/null` Should probably be: `gcc -v -x c -E -mtune=native /dev/null` Right ? Regards, -- jhell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It looks like the stack somehow mangled before entering strlen()? I'm somehow confused with this... Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLqVdzAAoJEATO+BI/yjfBWCkH/074A9sBUlo8hBTCPM68fVo1 UNRJrqa3fuATryjSeoQnXtB9lL48v2qESQ083t8deOlX/dHlS8FNuZ5GUdw11R91 RrZkoIRUd4pqCfC55R7Kov/TVusV6iSm7rDQJljczYB/OAsy435kSURCP6ZmGnlp TPp8rMRIUryQ7vy98T0OQODsBZsc6I+5K1GhTD2/zEw3PtpHiV7nxAvHqmyXJp39 hvMt9ZqVpg+JlIXmnv5KXLRdZXeezKxB1oXWQ3KcUAXpi+CV5pnyd/GczfW+zAjl G0hv2BgEs6Vwy51OY2pPJR9QFk6F5H1srdryxHuXUpCgo7WM+V1aG65P4jXOADQ= =lx4U -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On 2010-03-21 22:20, Garrett Cooper wrote: From gcc(1): -s Remove all symbol table and relocation information from the exe- cutable. This is more or less the same as running strip(1) over the produced executables. Usually one uses it for non-debug builds. That seems a bit harsh (especially because that makes certain libraries uses kind of moot, like *_p.a, right?). No, since -s only applies to the linking stage, so for executables or shared libraries. It does not apply to object files or libraries. It could be argued that -s really belongs in LDFLAGS... :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
on 22/03/2010 00:12 Alexander Best said the following: Andriy Gapon schrieb am 2010-03-21: on 21/03/2010 23:11 Alexander Best said the following: *hehe* that makes more sense. well i already sent you lp. unfortunately str is not available to gdb: (gdb) print str Variable str is not available. In cases like this sometimes the argument is still available for examination as a variable further down the stack (i.e. in one of the calling functions). hmmm... str might be -m then, because of: #1 0x00416782 in concat (first=0x417618 -m) at /usr/src/gnu/usr.bin/cc/libiberty/../../../../contrib/gcclibs/libiberty/concat.c:76 Perhaps, but doesn't look like it. Could you please do 'print *lp'? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
Andriy Gapon schrieb am 2010-03-22: on 22/03/2010 00:12 Alexander Best said the following: Andriy Gapon schrieb am 2010-03-21: on 21/03/2010 23:11 Alexander Best said the following: *hehe* that makes more sense. well i already sent you lp. unfortunately str is not available to gdb: (gdb) print str Variable str is not available. In cases like this sometimes the argument is still available for examination as a variable further down the stack (i.e. in one of the calling functions). hmmm... str might be -m then, because of: #1 0x00416782 in concat (first=0x417618 -m) at /usr/src/gnu/usr.bin/cc/libiberty/../../../../contrib/gcclibs/libiberty/concat.c:76 Perhaps, but doesn't look like it. Could you please do 'print *lp'? (gdb) print *lp Cannot access memory at address 0xc092f0 -- Alexander Best ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Sun, Mar 21, 2010 at 7:29 PM, jhell jh...@dataix.net wrote: Native is equal to CPUTYPE not being defined right ? Built into GCC is the ability to auto-detect the CPUTYPE when -mtune=native, if you run this command GCC will tell ouput your processor type: gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 | grep mtune | sed -e 's/.*mtune=//' So if the above is true why would you set CPUTYPE to native in the first place ? when you can just leave it unset and its equal to native. Native allows one to build the sources to the current build machines cputype. There is one bug when setting the CPUTYPE to native, the FreeBSD build system fails to correctly set the MACHINE_CPU to the correct value. I had discovered this problem back in May 2007: http://www.freebsd.org/cgi/query-pr.cgi?pr=112997 Just apply the last patch to share/mk/bsd.cpu.mk and that will fix the problem. Scot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
Garrett Cooper schrieb am 2010-03-21:
On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best alexbes...@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 21
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 21
for now i'm using the attached patch to prevent myself from shooting me in the
foot again. ;)
cheers.
alex
Cheers,
-Garrett
--
Alexander Best
Index: share/mk/bsd.cpu.mk
===
--- share/mk/bsd.cpu.mk (revision 205390)
+++ share/mk/bsd.cpu.mk (working copy)
@@ -53,10 +53,16 @@
CPUTYPE = athlon-mp
. elif ${CPUTYPE} == k7
CPUTYPE = athlon
+#XXX: compiling gcc with -march=native causes libc problems
+. elif ${CPUTYPE} == native
+.error CPUTYPE native is not supported.
. endif
. elif ${MACHINE_ARCH} == amd64
. if ${CPUTYPE} == prescott || ${CPUTYPE} == core2
CPUTYPE = nocona
+#XXX: compiling gcc with -march=native causes libc problems
+. elif ${CPUTYPE} == native
+.error CPUTYPE native is not supported.
. endif
. endif
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best alexbes...@wwu.de wrote: Garrett Cooper schrieb am 2010-03-21: On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best alexbes...@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 21 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 21 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 21 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
on 21/03/2010 13:43 Garrett Cooper said the following: Works for me *shrugs*: $ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 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 Do you also have the latest version of libc _installed_ in the system? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
Garrett Cooper schrieb am 2010-03-21: On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best alexbes...@wwu.de wrote: Garrett Cooper schrieb am 2010-03-21: On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best alexbes...@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 21 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 21 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 21 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 make.conf Description: Binary data src.conf Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
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 21 I didnt think you could add CPUTYPE=native to the /etc/make.conf What I used to do when I was compiling native was to do something like the following in the /etc/make.conf CPUTYPE?=core2 NO_CPU_CFLAGS= CFLAGS= -mtune=native -O2 -fno-strict-aliasing -pipe -s Peg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
Pegasus Mc Cleaft schrieb am 2010-03-21: 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 21 I didnt think you could add CPUTYPE=native to the /etc/make.conf What I used to do when I was compiling native was to do something like the following in the /etc/make.conf no you can. /usr/share/mk/bsd.cpu.mk doesn't perform any 'native' checks so when you set 'CPUTYPE=native' -mtune gets set to native. so you can just do: CPUTYPE=native CFLAGS=-O2 -fno-strict-aliasing -pipe -s btw: what's the -s switch doing? alex CPUTYPE?=core2 NO_CPU_CFLAGS= CFLAGS= -mtune=native -O2 -fno-strict-aliasing -pipe -s Peg -- Alexander Best ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
on 21/03/2010 14:35 Alexander Best said the following: Andriy Gapon schrieb am 2010-03-21: on 21/03/2010 13:43 Garrett Cooper said the following: Works for me *shrugs*: $ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 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 Do you also have the latest version of libc _installed_ in the system? i think so. i grabbed a fresh src copy yesterday and did buildworld/installworld a few ours ago. i've attached the output of `ident /lib/libc.so.7`. The question was for Garrett :) -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
Andriy Gapon schrieb am 2010-03-21: on 21/03/2010 14:35 Alexander Best said the following: Andriy Gapon schrieb am 2010-03-21: on 21/03/2010 13:43 Garrett Cooper said the following: Works for me *shrugs*: $ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 21 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 Do you also have the latest version of libc _installed_ in the system? i think so. i grabbed a fresh src copy yesterday and did buildworld/installworld a few ours ago. i've attached the output of `ident /lib/libc.so.7`. The question was for Garrett :) *lol* sorry. ;) -- Alexander Best ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Sun, 21 Mar 2010 13:43:52 +0100 (CET) Alexander Best alexbes...@wwu.de wrote: Pegasus Mc Cleaft schrieb am 2010-03-21: 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 21 I didnt think you could add CPUTYPE=native to the /etc/make.conf What I used to do when I was compiling native was to do something like the following in the /etc/make.conf no you can. /usr/share/mk/bsd.cpu.mk doesn't perform any 'native' checks so when you set 'CPUTYPE=native' -mtune gets set to native. so you can just do: CPUTYPE=native CFLAGS=-O2 -fno-strict-aliasing -pipe -s btw: what's the -s switch doing? It silences make. See the man page. It's useful because basically only errors are emitted. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Sun, 21 Mar 2010 14:03:04 +0100 Gary Jennejohn gary.jennej...@freenet.de wrote: On Sun, 21 Mar 2010 13:43:52 +0100 (CET) Alexander Best alexbes...@wwu.de wrote: Pegasus Mc Cleaft schrieb am 2010-03-21: 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 21 I didnt think you could add CPUTYPE=native to the /etc/make.conf What I used to do when I was compiling native was to do something like the following in the /etc/make.conf no you can. /usr/share/mk/bsd.cpu.mk doesn't perform any 'native' checks so when you set 'CPUTYPE=native' -mtune gets set to native. so you can just do: CPUTYPE=native CFLAGS=-O2 -fno-strict-aliasing -pipe -s btw: what's the -s switch doing? It silences make. See the man page. It's useful because basically only errors are emitted. Oops. That's wrong. I got confused. I'd like to know that myself, now that I'm no longer confused :) -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
on 21/03/2010 14:53 Alexander Best said the following: *lol* sorry. ;) No worries. BTW, when that rash happens, are you able to examine the core with gdb? Is it possible to examine values of 's' and 'p' in strlen? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On 2010-03-21 14:08, Gary Jennejohn wrote: CPUTYPE=native CFLAGS=-O2 -fno-strict-aliasing -pipe -s btw: what's the -s switch doing? It silences make. See the man page. It's useful because basically only errors are emitted. Oops. That's wrong. I got confused. I'd like to know that myself, now that I'm no longer confused :) From gcc(1): -s Remove all symbol table and relocation information from the exe- cutable. This is more or less the same as running strip(1) over the produced executables. Usually one uses it for non-debug builds. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
Andriy Gapon schrieb am 2010-03-21: on 21/03/2010 14:53 Alexander Best said the following: *lol* sorry. ;) No worries. BTW, when that rash happens, are you able to examine the core with gdb? Is it possible to examine values of 's' and 'p' in strlen? 'p' is not available. i guess because the segfault happens before 'p' gets assigned. but mask01 = 0x101010101010101 and lp = (const long unsigned int *) 0xc092d8. but i'm not really familiar with gdb and debugging. so you might want to ask for certain commands. ;) alex -- Alexander Best ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
on 21/03/2010 20:46 Alexander Best said the following: Andriy Gapon schrieb am 2010-03-21: on 21/03/2010 14:53 Alexander Best said the following: *lol* sorry. ;) No worries. BTW, when that rash happens, are you able to examine the core with gdb? Is it possible to examine values of 's' and 'p' in strlen? 'p' is not available. i guess because the segfault happens before 'p' gets assigned. but mask01 = 0x101010101010101 and lp = (const long unsigned int *) 0xc092d8. but i'm not really familiar with gdb and debugging. so you might want to ask for certain commands. ;) Not sure what I was dreaming of when I wrote my request. I actually meant 'str' and 'lp'. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
Andriy Gapon schrieb am 2010-03-21: on 21/03/2010 20:46 Alexander Best said the following: Andriy Gapon schrieb am 2010-03-21: on 21/03/2010 14:53 Alexander Best said the following: *lol* sorry. ;) No worries. BTW, when that rash happens, are you able to examine the core with gdb? Is it possible to examine values of 's' and 'p' in strlen? 'p' is not available. i guess because the segfault happens before 'p' gets assigned. but mask01 = 0x101010101010101 and lp = (const long unsigned int *) 0xc092d8. but i'm not really familiar with gdb and debugging. so you might want to ask for certain commands. ;) Not sure what I was dreaming of when I wrote my request. I actually meant 'str' and 'lp'. *hehe* that makes more sense. well i already sent you lp. unfortunately str is not available to gdb: (gdb) print str Variable str is not available. alex -- Alexander Best ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Sun, Mar 21, 2010 at 8:35 AM, Dimitry Andric dimi...@andric.com wrote: On 2010-03-21 14:08, Gary Jennejohn wrote: CPUTYPE=native CFLAGS=-O2 -fno-strict-aliasing -pipe -s btw: what's the -s switch doing? It silences make. See the man page. It's useful because basically only errors are emitted. Oops. That's wrong. I got confused. I'd like to know that myself, now that I'm no longer confused :) From gcc(1): -s Remove all symbol table and relocation information from the exe- cutable. This is more or less the same as running strip(1) over the produced executables. Usually one uses it for non-debug builds. That seems a bit harsh (especially because that makes certain libraries uses kind of moot, like *_p.a, right?). Cheers, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Sun, Mar 21, 2010 at 2:11 PM, Alexander Best alexbes...@wwu.de wrote: Andriy Gapon schrieb am 2010-03-21: on 21/03/2010 20:46 Alexander Best said the following: Andriy Gapon schrieb am 2010-03-21: on 21/03/2010 14:53 Alexander Best said the following: *lol* sorry. ;) No worries. BTW, when that rash happens, are you able to examine the core with gdb? Is it possible to examine values of 's' and 'p' in strlen? 'p' is not available. i guess because the segfault happens before 'p' gets assigned. but mask01 = 0x101010101010101 and lp = (const long unsigned int *) 0xc092d8. but i'm not really familiar with gdb and debugging. so you might want to ask for certain commands. ;) Not sure what I was dreaming of when I wrote my request. I actually meant 'str' and 'lp'. *hehe* that makes more sense. well i already sent you lp. unfortunately str is not available to gdb: (gdb) print str Variable str is not available. Sadly it may have been optimized out, which means that the best way to resolve that little item is to compile with -O0 and DEBUG_FLAGS=-g HTH, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
on 21/03/2010 23:11 Alexander Best said the following: *hehe* that makes more sense. well i already sent you lp. unfortunately str is not available to gdb: (gdb) print str Variable str is not available. In cases like this sometimes the argument is still available for examination as a variable further down the stack (i.e. in one of the calling functions). -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
Andriy Gapon schrieb am 2010-03-21: on 21/03/2010 23:11 Alexander Best said the following: *hehe* that makes more sense. well i already sent you lp. unfortunately str is not available to gdb: (gdb) print str Variable str is not available. In cases like this sometimes the argument is still available for examination as a variable further down the stack (i.e. in one of the calling functions). hmmm... str might be -m then, because of: #1 0x00416782 in concat (first=0x417618 -m) at /usr/src/gnu/usr.bin/cc/libiberty/../../../../contrib/gcclibs/libiberty/concat.c:76 -- Alexander Best ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Sun, 21 Mar 2010 07:00, alexbestms@ wrote: Garrett Cooper schrieb am 2010-03-21: On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best alexbes...@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 21 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 21 for now i'm using the attached patch to prevent myself from shooting me in the foot again. ;) cheers. alex Cheers, -Garrett Native is equal to CPUTYPE not being defined right ? So if the above is true why would you set CPUTYPE to native in the first place ? when you can just leave it unset and its equal to native. Nowhere in /usr/share/examples/etc/make.conf do I see a referance to this type of CPUTYPE so unless I am totally missing the point of this thread, I do not see a problem that has to be fixed. With all due respect, -- jhell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
i still haven't been able to do a buildworld without cc segfaulting. :( if i repeat the cc operation that segfaulted during buildworld with cc under /usr/bin everything works fine. the segfault only occurs during buildworld with the bootstrapped version of cc under /usr/ob/usr/src/tmp/usr/bin/cc. i've replaced my /bin /sbin /lib /libexec /usr/bin /usr/sbin /usr/lib /usr/lib32 /usr/libdata /usr/libexec directories completely and recursively with ones built 19th of March (so the strlen bug should be fixed in all those files because they have been dynamically or statically linked gainst a good libc) i've compared the output of `ident /usr/bin/cc` and `ident /usr/obj/usr/src/tmp/usr/bin/cc` and this is the result: -/usr/bin/cc: +/usr/obj/usr/src/tmp/usr/bin/cc: $FreeBSD: src/lib/csu/amd64/crti.S,v 1.7 2004/03/21 01:39:01 peter Exp $ $FreeBSD: src/lib/csu/amd64/crtn.S,v 1.6 2004/03/21 01:39:01 peter Exp $ $FreeBSD: src/lib/csu/common/crtbrand.c,v 1.6 2007/12/04 12:18:43 kib Exp $ $FreeBSD: src/lib/csu/amd64/crt1.c,v 1.16 2010/03/05 13:28:05 uqs Exp $ $FreeBSD: src/lib/libc/string/strsignal.c,v 1.9 2010/01/24 10:35:26 ume Exp $ + $FreeBSD: src/lib/libc/amd64/string/memcmp.S,v 1.2 2008/11/02 01:10:54 peter Exp $ $FreeBSD: src/lib/libc/stdio/remove.c,v 1.9 2007/01/09 00:28:07 imp Exp $ $FreeBSD: src/lib/libc/stdio/freopen.c,v 1.21 2008/04/17 22:17:54 jhb Exp $ $FreeBSD: src/lib/libc/gen/waitpid.c,v 1.7 2007/01/09 00:27:56 imp Exp $ @@ -51,7 +52,6 @@ $FreeBSD: src/lib/libc/stdio/fread.c,v 1.17 2010/01/10 14:30:30 cperciva Exp $ $FreeBSD: src/lib/libc/stdio/fileno.c,v 1.13 2008/05/05 16:03:52 jhb Exp $ $FreeBSD: src/lib/libc/stdio/ferror.c,v 1.12 2008/05/05 16:03:52 jhb Exp $ - $FreeBSD: src/lib/libc/stdio/puts.c,v 1.11 2007/01/09 00:28:07 imp Exp $ $FreeBSD: src/lib/libc/gen/syslog.c,v 1.39 2007/01/09 00:27:55 imp Exp $ $FreeBSD: src/lib/libc/string/strstr.c,v 1.6 2009/02/03 17:58:20 danger Exp $ $FreeBSD: src/lib/libc/string/strlcpy.c,v 1.11 2009/02/28 05:15:02 das Exp $ i'm really clueless right now. i thought maybe this could be due to bad memory, but in that case shouldn't segfaults appear randomly? because this one is 100% reproducable. maybe a bad sector in my hdd? i don't know. :( cheers. alex ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
on 21/03/2010 02:55 Alexander Best said the following: 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. Interestingly enough, there have recent commits to lib/libc/string/strlen.c. 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! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best alexbes...@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. Cheers, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Wednesday 17 March 2010 02:22:48 Alexander Best wrote: so is there no way to fix this? this is what i've tried and still the problem exists: Alex, I finally got my machine all back up and running. I'll tell you what I did and maybe it might help your situation. The only difference I see between us is that I was getting Sig10's to your Sig11's.. I dont know if this is significant or if the two are kind of the same thing Something horrible happened during memory access. But after I had installed the kernel and world with the strlen bug in it, the machine wouldn't boot as zfsloader was dieing at boot-time right after the bios disk scan. I was able to bring the machine up from a USB drive I had made previously (for just such an occasion : ). Once I had a machine that I could work with, I mounted the zfs filing systems as an altroot. I replaced the zfsloader with the zfsloader.old and the loader with loader.old. At this point I was able to boot the machine and try to bring it on-line. Unfortunately many of the daemons were dieing with sig10's and X/KDE would do nothing. I found that the shared library /lib/libc.so.7 was the culprit and I replaced this lib with a backup copy that I had from a friends machine that was built 3 days prior. Everything worked fine on the machine, but I was not able to build the world or kernel. What I did was create a virtual machine using VBox for Current-9 AMD64, svn the latest sources and build on this with the same kernconf file that I used on the host machine. After the build was completed, I copied /usr/lib/[libc.a, libc.so, libc_p.a] from the vbox machine to the host. It looked like these contained the bug and when the build was making some of its tools, it was using these libs (and then dieing). It was now that I am able to compile the latest world and kernel. I hope this helps, Peg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
hi there,
i'm having similar issues with libc. while doing buildworld i got this
segfault:
stage 4.2: building libraries
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64
CPUTYPE=native GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
_SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION=FreeBSD 9.0-CURRENT amd64
99 INSTALL=sh /usr/src/tools/install.sh
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
NO_CTF=1 /usr/obj/usr/src/make.amd64/make -f Makefile.inc1
DESTDIR=/usr/obj/usr/src/tmp -DNO_FSCHG -DWITHOUT_HTML -DWITHOUT_INFO
-DNO_LINT -DWITHOUT_MAN -DWITHOUT_PROFILE libraries
cd /usr/src; /usr/obj/usr/src/make.amd64/make -f Makefile.inc1 _prereq_libs;
/usr/obj/usr/src/make.amd64/make -f Makefile.inc1 _startup_libs;
/usr/obj/usr/src/make.amd64/make -f Makefile.inc1 _prebuild_libs;
/usr/obj/usr/src/make.amd64/make -f Makefile.inc1 _generic_libs;
=== gnu/lib/libssp/libssp_nonshared (obj,depend,all,install)
rm -f .depend
mkdep -f .depend -a-DHAVE_CONFIG_H
-I/usr/src/gnu/lib/libssp/libssp_nonshared/..
-I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp
-I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include
-DPIC
/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c
cc -O2 -fno-strict-aliasing -fno-builtin -pipe -march=native -DHAVE_CONFIG_H
-I/usr/src/gnu/lib/libssp/libssp_nonshared/..
-I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp
-I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include
-fPIC -DPIC -fvisibility=hidden -g -std=gnu99 -fstack-protector -c
/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c
*** Signal 11
Stop in /usr/src/gnu/lib/libssp/libssp_nonshared.
*** 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.
i'm not sure if the gdb command i used is correct, since i found two versions
of `cc` in /usr/obj:
find ./ -type f -name cc
./usr/src/tmp/usr/bin/cc
./usr/src/tmp/usr/src/gnu/usr.bin/cc/cc/cc
i've used gdb /usr/obj/usr/src/tmp/usr/bin/cc
/usr/obj/usr/src/gnu/lib/libssp/libssp_nonshared/cc.core to get a backtrace.
hope i picked the right version:
Program terminated with signal 11, Segmentation fault.
#0 strlen (str=Variable str is not available.
) at /usr/src/lib/libc/string/strlen.c:93
93 if ((*lp - mask01) mask80) {
(gdb) bt
#0 strlen (str=Variable str is not available.
) at /usr/src/lib/libc/string/strlen.c:93
#1 0x00415681 in concat (first=0x4408d3 -m) at
/usr/src/gnu/usr.bin/cc/libiberty/../../../../contrib/gcclibs/libiberty/concat.c:76
#2 0x00404d07 in do_spec_1 (spec=0x8008b20e0 %march=native
%:local_cpu_detect(arch) %{!mtune=*:%mtune=native
%:local_cpu_detect(tune)}, inswitch=0, soft_matched_part=0x0) at
/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5520
#3 0x0040580a in handle_braces (p=0x443d6b }
%{mtune=native:%mtune=native %:local_cpu_detect(tune)}) at
/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884
#4 0x00403fc4 in do_spec_1 (spec=0x443a48 %{!mtune*:
%{m386:mtune=i386 %n`-m386' is deprecated. Use `-march=i386' or `-mtune=i386'
instead.\n} %{m486:-mtune=i486 %n`-m486' is deprecated. Use `-march=i486' or
`-mtune=i486' instead.\n} %{mpentium..., inswitch=0,
soft_matched_part=0x0) at
/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274
#5 0x00404f6a in do_spec_1 (spec=0x440e2a %(cc1_cpu) %{profile:-p},
inswitch=0, soft_matched_part=0x0) at
/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5373
#6 0x00404694 in do_spec_1 (spec=0x60
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}
%1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*} %{c|S:%{o*:-auxbase-strip
%*}%{!o*:-auxbase %b}}%{!c:%{!S:-auxbase %b}} %{g*..., inswitch=0,
soft_matched_part=0x0) at
/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5193
#7 0x00404f6a in do_spec_1 (spec=0x8008721c0 \t\tcc1
%(cpp_unique_options) %(cc1_options), inswitch=0, soft_matched_part=0x0) at
/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5373
#8 0x0040580a in handle_braces (p=0x80080818f }) at
/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5884
#9 0x00403fc4 in do_spec_1 (spec=0x800808150
%{!no-integrated-cpp:\t\tcc1 %(cpp_unique_options) %(cc1_options)},
inswitch=0, soft_matched_part=0x0) at
/usr/src/gnu/usr.bin/cc/cc/../../../../contrib/gcc/gcc.c:5274
#10 0x0040580a
Re: build failures after stdlib update
On 2010-Mar-13 18:31:19 +, Pegasus Mc Cleaft k...@mthelicon.com wrote: I am not able to build the latest world (I havent tried kernel yet). Whenever I start gengtype dies with a signal 10. One problem is that much of the toolchain is statically linked so once you have a corrupted libc function, the toolchain is likely to also be corrupt and unable to be fixed my replacing libc.so. -- Peter Jeremy pgp7fpbO51kJ7.pgp Description: PGP signature
Re: build failures after stdlib update
so is there no way to fix this? this is what i've tried and still the problem exists: 1. backup /etc 2. `wget -r ftp://ftp.allbsd.org/pub/FreeBSD-snapshots/amd64/9.0-HEAD-20100222-JPSNAP/ftp/base/` (this shnapshot shouldn't contain the libc bug) 3. then i ran the install.sh script in that directory 4. and replaced /etc with the backup version yet gcc still segfaults during buildworld. :( thanks go out to delphij, nox---, jilles, garrcoop, x6b and joerg on #bsddev for helping me with this problem. :) -- Alexander Best ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Wednesday 17 March 2010 02:22:48 Alexander Best wrote: so is there no way to fix this? this is what i've tried and still the problem exists: One thing I am trying (and I have no idea if it will work yet) is seeing if replacing the /usr/lib/libc* archives with a working set from another machine. I am just guessing here, but it looks like the /lib/libc.so.7 that I replaced is only used for dynamic linked executables (and is the reason most of my machine is working after I replaced it). When the tool chain compiles, it does so statically and I believe the archive's it uses are in /usr/lib (and I haven't changed them yet). What I am trying to do is build another 9-current AMD64 in Vbox and when that compile is finished, copy the pieces over to the host machine. I'll let you know if this works. Peg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
On Sat, Mar 13, 2010 at 10:31 AM, Pegasus Mc Cleaft k...@mthelicon.com wrote: Hello Current, I am wondering if someone could help me please. I built the 9.0-current kernel and world while there was still a bug in the updated strlen(). Unfortunately this rendered the machine unbootable as gptzfsloader crashed and would just echo an endless stream of spaces across the screen. After booting off another drive and reverting the gptzfsboot to the .old version, I was able to being the machine back to life, but applications were dieing left and right (Signal 10). I used dgb to find the offending library /lib/libc.so.7 and had a copy of the library from 3 days ago. After reverting that library, I was able to start all my applications OK and the machine is working.. However. I am not able to build the latest world (I havent tried kernel yet). Whenever I start gengtype dies with a signal 10. I have tried to use dgb to examine the core file, but it gives me nonsense answers so I am not able to locate what library it might be trying to use. I have also tried to blow away the /usr/src and /usr/obj directories and recreate them from svn just incase there was something hanging on from the previous build. Can anyone give me advice on how to track this problem down or fix it? I suspect I still have a lib that still trying to use the broken libc.so.7 or something else depended on it, but I am not sure.. Some of the items in this commit may be causing the bad juju you're seeing on the screen: http://svn.freebsd.org/changeset/base/205021 Please try reverting that and see how things go. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: build failures after stdlib update
Can anyone give me advice on how to track this problem down or fix it? I suspect I still have a lib that still trying to use the broken libc.so.7 or something else depended on it, but I am not sure.. Some of the items in this commit may be causing the bad juju you're seeing on the screen: http://svn.freebsd.org/changeset/base/205021 Please try reverting that and see how things go. Hi Garrett, I'm not exactly sure if I can. I can use the svn utility OK, but the build looks like it is dieing when it makes the /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/* stuff. I was able to progress the build a little further by coping the build binaries from the /usr/obj/tmp/usr/../cc/cc_tools directory and then continuing the build with a NO_CLEAN. I found that the binaries that were dieing were statically linked and the ones that worked were dynamically linked to /lib/libc.so.7. I thought I was able to push through the problem, but it died later on with pages of bad references: (single example below) /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(cfgexpand.o) (.text+0xc6d): In function `add_reg_br_prob_note': : undefined reference to `gen_rtx_EXPR_LIST' I havent tried rolling back the sources yet, but I will give it a try. My suspicion is that the build will die because I have some library with a bug in it still. One option I was thinking of is copying in all the old libraries in /lib and seeing if it will build then. Do you think that will be helpfull? Peg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
