81869 2005-02-13 08:55 0000 maxima-5.9.1-r1 doesn't compile with GCL 2.6.6 2005-08-20 11:18:57 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified x86 All RESOLVED FIXED P2 major --- 1 mikos@sg1.cz sci@gentoo.org cbm@m.fsf.org lpetersen@gmx.net znmeb@cesmail.net mikos@sg1.cz 2005-02-13 08:55:12 0000 Hello, I have tried to emerge maxima (computer algebra system) with latest GCL, but it doesn't work. It has worked with previous version of GCL, but that old version isn't in portage anymore. First problem was missing "ansi" USE-flag in new GCL ebuild. This is now resolved (see my bug <a href="http://bugs.gentoo.org/show_bug.cgi?id=80749">#80749</a>), but Maxima doesn't compile even with ANSI support enabled in GCL. I have tried to compile GCL with GCC-3.3 and GCC-3.4 (and have tried less agressive CFLAGS - only "-O2 -march=athlon-xp"), but nothing works. This is error from "emerge maxima": Code: Summary: GCL enabled. Executable name: "gcl" default lisp: gcl wish executable name: "wish" Making all in src make[1]: Entering directory `/var/tmp/portage/maxima-5.9.1-r1/work/maxima-5.9.1/ src' test -d binary-gcl || mkdir binary-gcl test -d binary-gcl/numerical || mkdir binary-gcl/numerical test -d binary-gcl/numerical/slatec || mkdir binary-gcl/numerical/slatec gcl -batch -eval '(progn (load "../lisp-utils/defsystem.lisp") (funcall (intern "OPERATE-ON-SYSTEM" :mk) "maxima" :compile :verbose t))' && \ gcl -batch -eval '(progn (load "../lisp-utils/defsystem.lisp") (funcall (intern "OPERATE-ON-SYSTEM" :mk) "maxima" :load :verbose t) (when (fboundp (quote si::sg c-on))(si::sgc-on t)) (si:save-system "binary-gcl/maxima"))' make[1]: *** [binary-gcl/maxima] Error 139 make[1]: Leaving directory `/var/tmp/portage/maxima-5.9.1-r1/work/maxima-5.9.1/s rc' make: *** [all-recursive] Error 1 !!! ERROR: sci-mathematics/maxima-5.9.1-r1 failed. !!! Function src_compile, Line 62, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. --- I have tried Maxima also with CLISP, it works, but clisp is known to be extremely slow in comparison with gcl, cmucl or sbcl (and I don't want to use cmucl or sbcl, because it doesn't support readline). znmeb@cesmail.net 2005-02-13 15:38:06 0000 I just tried this from "raw" source. I emerged the latest gcl with the ANSI flag, then unpacked "/usr/portage/distfiles/maxima-5.9.1.tar.gz" in my home directory. Then I did ./configure --enable-gcl --prefix=$HOME make make check make install and everything worked. --------------------------------------------------------------------------- bash-2.05b$ bin/maxima Maxima 5.9.1 http://maxima.sourceforge.net Using Lisp GNU Common Lisp (GCL) GCL 2.6.6 (aka GCL) Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. This is a development version of Maxima. The function bug_report() provides bug reporting information. (%i1) sqrt(4); (%o1) 2 ------------------------------------------------------------------------ I also tried doing MAKEOPTS="-j1" USE="gcl -cmucl -clisp -sbcl -emacs -tetex -auctex" emerge -v maxima but it died the same way yours did. If it matters, I'm running dev-lisp/common-lisp-controller-4.12. One thing I did notice is that when I started up $HOME/bin/xmaxima, it came up in "clisp" rather than "gcl". I don't know if this means anything, but possibly if I exercise a few more options in the configure step on the build from raw source, I'll be able to reproduce the original problem. For now, if you don't need "xmaxima", you can build maxima with "gcl" from the source and use it in command line mode. Or, you can "emerge rlwrap" and emerge the fastest Lisp/maxima combination, which might be CMUCL/maxima, and do $ rmaxima from the command line. "rlwrap" is a package that allows any command-line tool to use "readline"; have a look at "/usr/bin/rmaxima" if you've got any version of maxima emerged. I'll check the maxima page to see which Lisp has the best performance. znmeb@cesmail.net 2005-02-13 15:51:50 0000 From the FAQ (maxima-5.9.0, cmucl-18), the cmucl inmplementation was considered the fastest. If you know of any benchmarks, I'll run them; I'm a performance engineer for a living so I care about this stuff. :) http://maxima.sourceforge.net/faq/faq.html: 4.1. What LISP implementations will Maxima work with? clisp, CMUCL and GCL are fully supported by Maxima; previous versions of Maxima only fully supported GCL. Ports to other ANSI lisps should be straightforward and are welcome; please contact the developers if you are interested in working on a port. 4.2. CLISP clisp includes GNU readline support, so Maxima will have advanced command-line editing facilities when built with it. Get it from http://clisp.cons.org. Maxima will fail to build with 2.26 because of a bug in clisp. 2.28 and 2.29 are known to work. There are currently unresolved problems with floating point numbers in Maxima with clisp 2.30. 2.29 is recommended. 4.3. CMUCL Get it from http://cmucl.cons.org. CMUCL is the fastest option for Maxima on platforms where it is available. Unfortunately, it does not include readline support. However, readline support can be added by wrapping maxima with the ledit executable. See ftp://ftp.inria.fr/INRIA/Projects/cristal/Daniel.de_Rauglaudre/Tools/ for ledit. Maxima will build with CMUCL 18c, but will hang on some run-time operations. 18d is known to work. 4.4. GCL Get it at <http://savannah.gnu.org/projects/gcl>. 2.4.4 and 2.5.0 should work. 2.5.0 has not yet been released as of this writing. The cvs version of 2.5.0 has been used to successfully build Maxima. GCL versions starting with 2.4.3 can be built with readline support, so Maxima will have advanced command-line editing facilities when build with it. lpetersen@gmx.net 2005-04-07 09:08:56 0000 I might have encountered the same error, and I could work around it by using FEATURES="-sandbox" emerge maxima As far as I have found out, gcl segfaults when run within portage's sandbox. You might try and put a line simply calling "gcl" into the src_unpack function of the ebuild to reproduce this. When run with the sandbox feature, it segfaults, and when run with deactivated sandbox, I end up with a gcl prompt without any problems. An "strace gcl" instead of "gcl" gives the following output in the sandboxed version: (...) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fce000 mprotect(0x46a79000, 8192, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7fce6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0$ munmap(0xb7fd0000, 157047) = 0 stat64("/lib/libsandbox.so", {st_mode=S_IFREG|0755, st_size=27716, ...}) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ whereas the same *without* the sandbox yields: (...) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fd7000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fd6000 mprotect(0x46a79000, 8192, PROT_READ) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7fd66c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0$ munmap(0xb7fd9000, 157047) = 0 open("/dev/urandom", O_RDONLY) = 3 read(3, "q\206\t\214", 4) = 4 close(3) = 0 getpid() = 18565 stat64("/proc/18565/exe", {st_mode=S_IFREG|0755, st_size=14840600, ...}) = 0 lstat64("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 lstat64("/proc/18565", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 lstat64("/proc/18565/exe", {st_mode=S_IFLNK|0777, st_size=0, ...}) = 0 readlink("/proc/18565/exe", "/usr/lib/gcl-2.6.6/unixport/saved_ansi_gcl", 4096) = 42 (... and lots more ...) If this turns out to be the same error as the original report was about, I can attach the two complete strace logs (approx. 15K and 50K bytes, respectively), if this might help a developer. lpetersen@gmx.net 2005-05-07 10:04:19 0000 Just another thought: I found the following two lines in emacs-22.0.50_pre20050225.ebuild: # Never use the sandbox, it causes Emacs to segfault on startup SANDBOX_DISABLED="1" Maybe this is a similar effect to the one leading to this bug? To the OP: Michal, can you confirm that this is the same problem you are experiencing at all? I.e., can you emerge maxima with the sandbox feature disabled? znmeb@cesmail.net 2005-06-02 23:33:37 0000 The bad news: this is still broken with maxima-5.9.1-r2. But the good news is that it looks like "dev-lisp/gcl-cvs-2.7.0" can compile maxima with no issues!! I haven't put the resulting maxima through any kind of tests yet, but it did compile. So ... shall we say, "fixed in GCL 2.7.0?" cbm@m.fsf.org 2005-07-30 01:19:05 0000 Re: comment #4. I tried emerging without userpriv and usersandbox in FEATURES in my make.conf and I still get the same error. Haven't tried the gcl-cvs ebuild mentioned in comment #5 yet. ribosome@gentoo.org 2005-08-17 18:28:42 0000 Compiling with GCL version 2.6.7 seems to fix the problem. Anyone can confirm? cbm@m.fsf.org 2005-08-17 19:11:23 0000 Yes gcl 2.6.7 fixed it for me! lpetersen@gmx.net 2005-08-18 00:48:36 0000 With gcl-2.6.7, maxima-5.9.1-r2 compiles and runs fine here as well. No sandbox problem any more. Thank you! (BTW: Isn't the status of this bug supposed to be changed to something other than "NEW" by now ... ;-) ?) ribosome@gentoo.org 2005-08-18 06:20:13 0000 I'd rather take the time to fix the ebuild to depend on the correct version before calling this fixed. I'll do that later today or tomorrow. znmeb@cesmail.net 2005-08-18 06:56:50 0000 Hmmm ... I can't get maxima-5.9.1-r2 to recompile with **any** Lisp now!!! What happened?? ribosome@gentoo.org 2005-08-20 11:18:57 0000 Ebuild fixed in CVS. Thanks to everyone who commented on this. Edward: There is probably a configuration problem with lisp on your machine. If you are sure lisp works Ok but Maxima still does not compile, please open a separate bug report (as this is a different problem). Thanks.