| Summary: | (common-lisp) cmucl-18e-r4 segv during build-world.sh | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andreas Scholta <ascholta> |
| Component: | New packages | Assignee: | Matthew Kennedy (RETIRED) <mkennedy> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | toolchain, znmeb |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Andreas Scholta
2004-02-28 04:34:35 UTC
The line:
sed -i -e 's,-I/usr/X11R6/include,/usr/X11R6/include/lesstif,g'
should read
sed -i -e 's,-I/usr/X11R6/include,-I/usr/X11R6/include/lesstif,g'
A fix for this (correction to -r4) will be out in a moment.
the last line in src_install (impl-save-timestamps-hack).. it seems that at least here, common-lisp-common.eclass is not parsed. "impl-save-timestamps-hack" is not defined by merely 'inheriting' the eclass. I am still having issues compiling cmucl - I do not have the lesstif USE variable (in fact I have it set to use motif), and it simply fails before really doing anything. Here is my compiler output: Calculating dependencies ...done! >>> emerge (1 of 2) dev-lisp/cmucl-18e-r4 to / >>> md5 src_uri ;-) cmucl_18e-8.tar.gz >>> md5 src_uri ;-) cmucl-18e-x86-linux.tar.bz2 >>> Unpacking source... >>> Unpacking cmucl_18e-8.tar.gz to /var/tmp/portage/cmucl-18e-r4/work >>> Unpacking cmucl-18e-x86-linux.tar.bz2 to /var/tmp/portage/cmucl-18e-r4/work RUNNING FROM extra_functions.sh * Applying herald-save.lisp-gentoo.patch... [ ok ] RUNNING FROM extra_functions.sh * Applying install-clc.lisp-gentoo.patch... [ ok ] >>> Source unpacked. ./build-tools/create-target.sh target linux_gencgc x86 || true ./build-tools/clean-target.sh target || true ./build-tools/build-world.sh target ./build-tools/build-world.sh: line 55: 12009 Segmentation fault $LISP "$@" -noinit -nositeinit <<EOF (in-package :cl-user) (setf (ext:search-list "target:") '("$TARGET/" "src/")) (when (probe-file "target:bootstrap.lisp") (load "target:bootstrap.lisp")) (load "target:setenv") (pushnew :no-clx *features*) (pushnew :no-clm *features*) (pushnew :no-hemlock *features*) (load "target:code/exports") (load "target:tools/setup" :if-source-newer :load-source) (comf "target:tools/setup" :load t) (setq *gc-verbose* nil *interactive* nil) (load "target:tools/worldcom") #-(or no-compiler runtime) (load "target:tools/comcom") ;; Compile at least new-genesis, so that genesis doesn't take ages #+(or no-compiler runtime) (comf "target:compiler/generic/new-genesis") #-(or no-pcl runtime) (load "target:tools/pclcom") (setq *gc-verbose* t *interactive* t) (load "target:tools/worldbuild") (ext:quit) EOF make: *** [all] Error 139 !!! ERROR: dev-lisp/cmucl-18e-r4 failed. !!! Function src_compile, Line 42, Exitcode 2 !!! (no error message) The root symptom is: ./build-tools/build-world.sh: line 55: 12009 Segmentation fault $LISP "$@" -noinit -nositeinit <<EOF I have seen one other user encounter this, but I have been unable to reproduce it (this morning I set up a fresh stage3/grp chrooted isntall specifically to try and reproduce this bug). Are you using GRSEC, "hardened" Linux or GCC options? The other interesting aspect of the error, is that it occurs with the CMUCL binary which is used to build a new binary from the CMUCL (unfortunately, CMUCL requires a CMUCL to compile itself). The CMUCL binary used to do the compilation of the CMUCL source in Gentoo is the official CMUCL distributed one for GNU/Linux. I would expect that if you downloaded the CMUCL binary distribution for GNU/Linux, that you would also get this problem -- could you verify that for me please? Can you provide more details of your environment? kernel/glibc/architecture (cpu etc), whether your running GRSEC etc. features and also the output of "emerge info" This is a separate bug from the original reporter's motif problems, hence the Summary change I had similar problems compiling cmucl-18e-r4. Besides, the one I had installed (cmucl-18e-r2) had started to segfault on load. I solved the problem by removing the system-wide prelink'ing I had done. My guess is that some need library was modified, and cmucl could not handle it. After removing the prelink, lisp starts and I can compile it without any problems. Hope this helpful to somebody. Thats interesting. Thanks for posting it here.
What is even more interesing is that I prelink my system (system-wide) also but can't reproduce this bug. I'm using ~x86, with linux 2.6.x, NPTL glibc etc.
I am using:
/usr/sbin/prelink -a
Andreas, could you let me know if you're still having problems. I will close this bug for now, feel free to re-open it if you have more information Any thoughts on resolving the prelink issue??? Prior to executing "prelink -ua", emerging resulted in the following error (cmucl-18e-r4):
------------------------------------------------------------------------------
./build-tools/build-world.sh: line 55: 20242 Segmentation fault (core dumped) $LISP "$@" -noinit -nositeinit <<EOF
(in-package :cl-user)
(setf (ext:search-list "target:")
'("$TARGET/" "src/"))
(when (probe-file "target:bootstrap.lisp")
(load "target:bootstrap.lisp"))
(load "target:setenv")
(pushnew :no-clx *features*)
(pushnew :no-clm *features*)
(pushnew :no-hemlock *features*)
(load "target:code/exports")
(load "target:tools/setup" :if-source-newer :load-source)
(comf "target:tools/setup" :load t)
(setq *gc-verbose* nil *interactive* nil)
(load "target:tools/worldcom")
#-(or no-compiler runtime) (load "target:tools/comcom")
;; Compile at least new-genesis, so that genesis doesn't take ages
#+(or no-compiler runtime) (comf "target:compiler/generic/new-genesis")
#-(or no-pcl runtime) (load "target:tools/pclcom")
(setq *gc-verbose* t *interactive* t)
(load "target:tools/worldbuild")
(ext:quit)
EOF
make: *** [all] Error 139
!!! ERROR: dev-lisp/cmucl-18e-r4 failed.
!!! Function src_compile, Line 40, Exitcode 2
!!! (no error message)
-----------------------------------------------------------------------------
Afterwards, no problems... prelinking is the culprit. Thanks for the heads up.
I think I'll re-open this one. I emerged CMUCL a few days ago and it was working. I did an "emerge sync" last night (27 June) and CMUCL started giving segfaults today. Given the segfaults, I attempted to re-emerge it and got similar complaints. I don't have "prelink" installed, so I think it's independent of that. I'll try doing another "emerge sync" before I attempt the CMUCL re-emerge again. Well ... "emerge sync" didn't help. Meanwhile: 1. "emerge clisp" now requires a library called "libsigsegv". It's been a while since I did anything with "clisp", but I don't remember this being required. 2. I checked the dates in "/usr/portage/dev-lisp/cmucl". They were last changed a few days ago: DreamTime cmucl # ls -l total 36 -rw-r--r-- 1 root root 1746 Jun 24 17:11 ChangeLog -rw-r--r-- 1 root root 1044 Jun 24 17:11 Manifest -rw-r--r-- 1 root root 3327 Jun 24 17:11 cmucl-18e-r1.ebuild -rw-r--r-- 1 root root 3195 Jun 24 17:11 cmucl-18e-r2.ebuild -rw-r--r-- 1 root root 3401 Jun 24 17:11 cmucl-18e-r3.ebuild -rw-r--r-- 1 root root 2888 Jun 24 17:11 cmucl-18e-r4.ebuild -rw-r--r-- 1 root root 2669 Jun 24 17:11 cmucl-18e.ebuild drwxr-xr-x 3 1005 1005 4096 Jun 7 16:06 files -rw-r--r-- 1 root root 1107 Feb 26 19:41 metadata.xml So ... my feeling that "something broke a working cmucl" may have been confirmed. I'm going to attempt to go back to r3, r2, ... and see what happens. Meanwhile, both "gcl" and "clisp" emerge fine. I'll also try "sbcl". Latest tests: 1. None of the ebuilds in "/usr/portage/dev-lisp/cmucl" work any more. 2, I downloaded the binary tarball for 18e from the CMUCL homepage. Guess what? The lisp executable from it segfaults! :(((( Bah Humpback! On my system if i compile cmucl with prelink segv during build After prelink -au cmucl build correct. Portage 2.0.50-r8 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.7-gentoo-r6) ================================================================= System uname: 2.6.7-gentoo-r6 i686 AMD Athlon(tm) MP 1700+ Gentoo Base System version 1.4.16 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /etc/tomcat /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/lib/jboss /var/qmail/control /var/www/localhost/htdocs//mythweb/config" CONFIG_PROTECT_MASK="/etc/afs/C /etc/afs/afsws /etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://sunsite.cnlab-switch.ch/mirror/gentoo/ ftp://planetmirror.com/pub/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X X509 aalib acl acpi acpi4linux afs aim alsa amd apache2 apm arts autofs avi berkdb bonobo cddb cdr clamav crypt cups curl dillo divx4linux doc dv dvb dvd dvdr emacs encode escreen esd etwin evms2 evo faad fam ffmpeg flac flash fmod foomaticdb gd gdbm geoip ggi gif gimp gimpprint gnome gnomedb gnuplot gphoto2 gpm gs gstreamer gtk gtk2 gtkhtml guile icq imagemagick imap imlib ipv6 jabber java javamail javascript jpeg kde kerberos ldirectord libdsk libg++ libgda libwww live mad mbox mcal mdb mikmod mmx monkey motif mozcalendar mozilla mozsvg mpeg mpeg4 mplayer msdav msn mysql nas ncurses net nls nvidia oav odbc oggvorbis openal opengl oscar oss pam pdflib perl pic png portaudio postgres ppds python qt quicktime readline ruby samba scanner sdl slang speex spell ssl svg svga tcltk tcpd tetex theora tiff transcode truetype type1 usb v4l v4l2 virus-scan wxwindows x86 xfs xine xml2 xmms xv xvid yahoo zlib" I've been testing the beta version of CMUCL 19a. It does the same thing. I joined the CMUCL mailing list and I've told them about this. It looks like an incompatibility between CMUCL and glibc. Specifically, the latest glibc in Portage seems to have claimed some memory map areas that previous versions didn't, and CMUCL was also using those. I suspect they are going to fix CMUCL so it is more careful about memory mapping. Meanwhile, other LISP-based functionality like MAXIMA is not working any more either on my system. I used GCL to build MAXIMA, and MAXIMA is now segfaulting :(. I saw another bug against the latest glibc that looked similar to what I'm getting -- not exactly a smoking gun, though, since it was on a PCC. If the CMUCL people come up with a 19a that runs on my system, I'll file a new bug to get the 19a version in Portage. I've been away from this for a week or so, but I'm back on it. I'm in the process of loading a different machine from scratch, starting with Gentoo 2004.1. CMUCL emerges and executes just fine on this system. Portage *wants* to upgrade "glibc": DreamSong root # emerge -pv glibc These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] sys-libs/glibc-2.3.3.20040420 [2.3.2-r9] -debug 15,671 kB but I'm not going to let that happen until I have everything else that I want loaded and running. From what the CMUCL folks have told me, the segfaults are coming from a memory map conflict between CMUCL and glibc 2.3.3. I'm adding "toolchain" to the CC list for this one, because I think it's a "glibc" issue. Please feel free to remove it. :) Well, if the issue is that cmucl mapped memory it should not have, and now glibc is using it, it will have to be fixed cmucl side. We might try to track the glibc change that broke it, but I have a feeling it might be in the loader, and patching that might get a nightmare. Also, I am pretty sure Ulrich Drepper wont change glibc for one app :/ Yeah ... I think the CMUCL gang is working on this ... they gave me some tests to run. I haven't heard anything from them since I sent them the logs, which is a little over a week ago. Meanwhile I have two machines, one that will run CMUCL and one that won't. Portage defends itself mightily if I try to "downgrade" glibc back to 2.3.2 on this machine, so I'll just have to do a full backup on the other maching, "upgrade" glibc, watch CMUCL crumble, then restore it. Just out of curiosity, are there other things that break when you upgrade glibc?? Not that I know of, but then I run a pretty standard devel box. Latest news: 1. I rebuilt the system back to 2004.1 and loaded CMUCL. I deliberately held off loading both the latest "glibc" and "gcc" until I had time to check this out. CMUCL was working fine. 2. I loaded the "gentoo-sources" with 2.4.26-r6, did a kernel build, and CMUCL started segfaulting. I rebooted back to the 2.4.25-r5 that comes with 2004.1 and CMUCL works just fine! So now I'm looking at kernel configurations trying to figure out what is going on. I haven't loaded the latest glibc or gcc yet, though. There is a new option in the 2.4.26 kernel having something to do with executable size. It defaults to 2 GB. I've never seen this before. I'm going to try pushing it up to 3.5 GB to see if that's what is giving CMUCL heartburn. 3. Just last night, the CMUCL team "formally" released 19a. I downloaded the Linux binary and it executes fine on the 2.4.25 kernel and segfaults on the 2.4.26 kernel. So ... it looks like it's OK to put the 19a CMUCL into the "testing" release. They have binaries for at least x86 Linux and SPARC. I'm not sure what else is there at the moment, but they do have source, of course. |
