|Summary:||cmucl borked on f9/gcc43|
|Product:||[Fedora] Fedora||Reporter:||Jesse Keating <jkeating>|
|Component:||cmucl||Assignee:||Rex Dieter <rdieter>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||9||CC:||dcantrell, green, jonstanley|
|Fixed In Version:||19e-0.3.pre2||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-07-08 03:53:31 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Jesse Keating 2008-02-22 16:08:48 UTC
This is an automatically filed bug for a failed rebuild attempt for GCC 4.3. http://fedoraproject.org/wiki/JesseKeating/gcc43MassRebuildProposal Please verify why this build failed and fix it. http://koji.fedoraproject.org/koji/taskinfo?taskID=444050 Unknown exit code, check the failed task.
Comment 1 Jon Stanley 2008-03-01 20:18:00 UTC
scratch build 482739
Comment 2 Jon Stanley 2008-03-02 06:01:21 UTC
Well this build ran a little on the long side :). Canceled it, downloaded the generated SRPM to my box and tried building it. Lisp took 100% of the CPU immediately when it started building, and attaching an strace to the lisp process gave me this pile of joy: --- SIGSEGV (Segmentation fault) @ 0 (0) --- sigreturn() = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- sigreturn() = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- sigreturn() = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- sigreturn() = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- The same build on F8 (both in mock on the same machine) resulted in pretty much similar results, except this was repeated in build.log *** Sigsegv in page not marked as write protected
Comment 3 Rex Dieter 2008-03-10 14:22:32 UTC
I'd venture this may have something to with the same problems sbcl has (see bug #434401). gcc43/kernel bug? sbcl devs pointed me to: "GCC 4.3.0 exposes a kernel bug" http://lwn.net/Articles/272048/ (I'm not currently an lwn subscriber, so can't access the article, yet).
Comment 4 Jon Stanley 2008-03-10 14:46:41 UTC
I just forwarded you a link to the LWN article (but I haven't read it yet). I also saw the problem on F8, which doesn't use gcc43, so I'm not inclined to believe that it's a gcc43 issue. But hey, you never know!
Comment 5 Rex Dieter 2008-03-10 15:23:30 UTC
As I understand it: unpatched kernel + gcc43-derived buildroot = boom
Comment 6 Rex Dieter 2008-03-13 16:25:57 UTC
joy, also would appear f8+ builds are broken due to kernel-header changes in /usr/include/asm/unistd.h which now contains: #ifdef __i386__ #include "unistd_32.h" #else #include "unistd_64.h" #endif which induces: gcc -m32 -rdynamic -Wstrict-prototypes -Wall -O2 -g -DGENCGC -DLINKAGE_TABLE -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -D__NO_CTYPE -D_GNU_SOURCE -I. -I../../src/lisp -I- -I/usr/X11R6/include -DGENCGC -DLINKAGE_TABLE -c -o lisp.o ../../src/lisp/lisp.c ... In file included from /usr/include/sys/syscall.h:25, from ../../src/lisp/Linux-os.h:25, from ../../src/lisp/os.h:41, from ../../src/lisp/lisp.c:25: /usr/include/asm/unistd.h:2:25: error: unistd_32.h: No such file or directory
Comment 7 Rex Dieter 2008-03-13 16:30:23 UTC
doh, looks like -I- is more to blame here.
Comment 8 Rex Dieter 2008-03-13 19:56:37 UTC
Tried out cmucl-19e-pre1, and this works better and gets further, but now fails in some asm in ../../src/lisp/x86-assem.S ../../src/lisp/x86-assem.S: Assembler messages: ../../src/lisp/x86-assem.S:84: Error: suffix or operands invalid for `fnstsw' See: http://koji.fedoraproject.org/koji/buildinfo?buildID=42817 (fwiw, cmucl-19e-pre1 builds fine on/for f8)
Comment 9 Bug Zapper 2008-05-14 05:31:50 UTC
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Matt Domsch 2008-07-08 03:53:31 UTC
builds as of 2008-07-03.