sci-mathematics/maxima-5.17.1-r1 fails to build with the followning error: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-10003.log" VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /usr/lib64/sbcl/sb-grovel/defpackage.fasl A: /usr/lib64/sbcl/sb-grovel/defpackage.fasl R: /usr/lib64/sbcl/sb-grovel/defpackage.fasl C: sbcl --noinform --noprint --eval (progn (load "../lisp-utils/defsystem.lisp") (funcall (intern (symbol-name :operate-on-system) :mk) "maxima" :compile :verbose t) (sb-ext:quit)) -------------------------------------------------------------------------------- ls -l /usr/lib64/sbcl/sb-grovel/defpackage.fasl gives: -rw-r--r-- 1 root root 1363 21. Mär 18:25 /usr/lib64/sbcl/sb-grovel/defpackage.fasl I tried to set other permissions but that does not solve the problem - and it shouldn't since emerge should not try to write to a file outside the sandbox, should it? Reproducible: Always Steps to Reproduce: 1. emerge =sci-mathematics/maxima-5.17.1-r1 Actual Results: emerge fails Expected Results: sci-mathematics/maxima-5.17.1-r1 gets emerged
From your paths I suppose you have an amd64 computer. I cannot reproduce your problem (but I have only ax x86 computer, so, some details can differ). Please attach your build log. Also, with what USE flags do you emerge maxima? I see the line in src/Makefile which runs sbcl with the parameters given in C: in the message you sent. It is trying to build binary-sbcl/maxima.core; in other words, this step is where all compilation of maxima by sbcl happens. For me, this step works fine. And, most definitely, it must not write anything to /usr. So, one thing you can check: cd /var/tmp/portage/sci-mathematics/maxima-5.17.1-r1/work/maxima-5.17.1/src make binary-sbcl/maxima.core (if binary-sbcl/maxima.core exists, remove it and run make again). Does maxima compilation secceed? Does this step write anything to /usr/lib64/sbcl/sb-grovel/ ? (you can use ls -l to check). By the way, do you already have /usr/lib64/sbcl/sb-grovel/defpackage.fasl? If so, check if it belongs to the sbcl package. On my computer, I see gdh-zimmer201 ~ # qfile /usr/lib/sbcl/sb-grovel/defpackage.fasl dev-lisp/sbcl (/usr/lib/sbcl/sb-grovel/defpackage.fasl) gdh-zimmer201 ~ # (qfile command comes from app-portage/portage-utils). If you don't have this file (or it is not owned by dev-lisp/sbcl), something is, probably, wrong with your sbcl. By the way, what version of sbcl do you use? Mine is sbcl-1.0.26-r10 (from the lisp overlay). I am not sure what's available in the main tree, but any sufficiently recent sbcl should be OK. Maybe, if you upgrade sbcl (perhaps, from the lisp overlay), your problem will disappear.
Created attachment 186127 [details] build log
Yes, I'm running amd64. My USE flags fore maxima are: X -clisp (-cmucl) -emacs -gcl latex nls sbcl tk unicode -xemacs /var/tmp/portage/sci-mathematics/maxima-5.17.1-r1/work/maxima-5.17.1/src/binary-sbcl/maxima.core did not exist but make succeeds. /usr/lib64/sbcl/sb-grovel/defpackage.fasl exists and belongs to dev-lisp/sbcl but gets modified by running the make command from above (as well as def-to-lisp.fasl and foreign-glue.fasl in the same directory). I use sbcl 1.0.26-r10, too. After running the make command from above I can emerge maxima - but it fails again as soon as I reemerge sbcl.
Hmm. This seems to be a strange behaviour of sbcl on amd64 (not seen on my x86). I'll ask sbcl developers about it. As a practical step, you can emerge maxima with another lisp. If maxima tests are somehow representative, the fastest lisp for maxima is gcl. WARNING! Only gcl from the lisp overlay works, the one in the tree is completely broken. The second-fastest is cmucl. clisp is slowest. So, if sbcl does not work for you, you have many other choices.
/me too, but on x86 using paludis: ; - Compiling module "server" ; - Compiling source file ; "/gentoo/build/sci-mathematics-maxima-5.17.1-r1/work/maxima-5.17.1/src/server.lisp" ; compiling file "/gentoo/build/sci-mathematics-maxima-5.17.1-r1/work/maxima-5.17.1/src/server.lisp" (written 27 JUL 2008 09:04:12 AM): ; compiling (IN-PACKAGE :MAXIMA) ; compiling (REQUIRE (QUOTE ASDF)) ; compiling (REQUIRE (QUOTE SB-POSIX)) ; loading #P"/usr/lib/sbcl/sb-posix/sb-posix.asd" ; loading system definition from /usr/lib/sbcl/sb-grovel/sb-grovel.asd into ; #<PACKAGE "ASDF1"> ;; loading #P"/usr/lib/sbcl/sb-grovel/sb-grovel.asd" ; registering #<SYSTEM SB-GROVEL {DE27241}> as SB-GROVEL ACCESS DENIED open_wr: /usr/lib/sbcl/sb-grovel/defpackage.fasl ISE:write_logfile unable to append logfile ISE open_wr(/usr/lib/sbcl/sb-grovel/defpackage.fasl): Permission denied abs_path: /usr/lib/sbcl/sb-grovel/defpackage.fasl res_path: /usr/lib/sbcl/sb-grovel/defpackage.fasl fatal error encountered in SBCL pid 30430(tid 1075674848): SIGABRT received. The system is too badly corrupted or confused to continue at the Lisp level. If the system had been compiled with the SB-LDB feature, we'd drop into the LDB low-level debugger now. But there's no LDB in this build, so we can't really do anything but just exit, sorry. make[1]: *** [binary-sbcl/maxima.core] Error 1 make[1]: Leaving directory `/gentoo/build/sci-mathematics-maxima-5.17.1-r1/work/maxima-5.17.1/src' make: *** [all-recursive] Error 1 As for USE flags: # paludis -ip maxima Building target list... Building dependency list... These packages will be installed: * sci-mathematics/maxima [U 5.17.1 -> 5.17.1-r1] <target> X -clisp -cmucl -emacs -gcl latex nls -sbcl tk unicode xemacs LINGUAS: -es -pt -pt_BR build_options: -optional_tests split strip Total: 1 package (1 upgrade) BTW: As you can see, this would be an update. 5.17.1 installed just fine. Maybe it's worth looking at the diff between those ebuilds?
Does the problem also happen if you emerge sbcl and maxima with Portage?
Question to everybody having this problem: Are *.fasl files in .../sbcl/sb-grovel created later than the corresponding *.lisp files? If not, then, naturally, ASDF (which is kinda lisp 'make') will want to re-compile these *.lisp files and write the corresponding fasls. If sbcl is installed properly, *.fasl files are created at the package installation time, i.e., later than the lisp files. On my computer: grozin@gdh-zimmer201 /usr/lib/sbcl/sb-grovel $ ls -lt total 304 -rw-r--r-- 1 root root 2592 Mar 13 02:53 sb-grovel.fasl -rw-r--r-- 1 root root 0 Mar 13 02:53 test-passed -rw-r--r-- 1 root root 122159 Mar 13 02:53 def-to-lisp.fasl -rw-r--r-- 1 root root 104079 Mar 13 02:53 foreign-glue.fasl -rw-r--r-- 1 root root 1353 Mar 13 02:53 defpackage.fasl drwxr-xr-x 2 root root 4096 Mar 1 21:26 CVS -rw-r--r-- 1 root root 16478 Dec 1 18:35 foreign-glue.lisp -rw-r--r-- 1 root root 579 Nov 24 16:56 sb-grovel.asd -rw-r--r-- 1 root root 11323 Aug 3 2008 def-to-lisp.lisp -rw-r--r-- 1 root root 1352 Jul 14 2005 example-constants.lisp -rw-r--r-- 1 root root 8651 Dec 9 2004 sb-grovel.texinfo -rw-r--r-- 1 root root 376 Jun 29 2004 defpackage.lisp -rw-r--r-- 1 root root 43 Apr 9 2003 Makefile grozin@gdh-zimmer201 /usr/lib/sbcl/sb-grovel $
They are all created at the same time: /usr/lib64/sbcl/sb-grovel $ ls -lt insgesamt 276 drwxr-xr-x 2 root root 4096 24. Mär 18:31 CVS -rw-r--r-- 1 root root 1362 24. Mär 18:31 defpackage.fasl -rw-r--r-- 1 root root 376 24. Mär 18:31 defpackage.lisp -rw-r--r-- 1 root root 99151 24. Mär 18:31 def-to-lisp.fasl -rw-r--r-- 1 root root 11323 24. Mär 18:31 def-to-lisp.lisp -rw-r--r-- 1 root root 1352 24. Mär 18:31 example-constants.lisp -rw-r--r-- 1 root root 97001 24. Mär 18:31 foreign-glue.fasl -rw-r--r-- 1 root root 16478 24. Mär 18:31 foreign-glue.lisp -rw-r--r-- 1 root root 43 24. Mär 18:31 Makefile -rw-r--r-- 1 root root 579 24. Mär 18:31 sb-grovel.asd -rw-r--r-- 1 root root 2558 24. Mär 18:31 sb-grovel.fasl -rw-r--r-- 1 root root 8651 24. Mär 18:31 sb-grovel.texinfo -rw-r--r-- 1 root root 0 24. Mär 18:31 test-passed /usr/lib64/sbcl/sb-grovel $
(In reply to comment #8) > They are all created at the same time: This bug is neither a problem of Maxima nor of SBCL. It is a well-known issue that Paludis does not preserve files' timestamps when merging them from ${D} to ${ROOT}. However, I wonder about the following (comment #0): > Steps to Reproduce: > 1. emerge =sci-mathematics/maxima-5.17.1-r1 which seems to indicate that the problem happens with Portage, too?
(In reply to comment #9) > This bug is neither a problem of Maxima nor of SBCL. It is a well-known issue > that Paludis does not preserve files' timestamps when merging them from ${D} > to ${ROOT}. This will prevent compilation of any non-trivial lisp application (using the standard lisp make system, ASDF). How to inform paludis devs about this issue?
(In reply to comment #10) > This will prevent compilation of any non-trivial lisp application (using the > standard lisp make system, ASDF). How to inform paludis devs about this issue? I have filed bug 264130 for PMS. So yes, Paludis devs are aware of it. The bad thing is that I know of no reasonable way to work around this problem. CMUCL and SBCL used to call impl-*-timestamp-hack of common-lisp-common-3.eclass, but that is really a horrible hack which effectively makes the installed files orphaned. So the eclass has to play package manager and remove them by itself in pkg_postrm. Another hack would be to touch the .fasl files in pkg_postinst and record their updated timestamps in /var/db/pkg/.../CONTENTS. Which I think is not allowed by PMS. ;-)
> which seems to indicate that the problem happens with Portage, too? I tried both, paludis and portage, to install maxima in order to make sure it was not the package manager's fault. But I'm afraid that I did not reemerge sbcl with portage since it seemed to install as expected. Using portage to emerge sbcl solved the problem for me. What does PMS say about timestamps?
(In reply to comment #12) > I tried both, paludis and portage, to install maxima in order to make sure it > was not the package manager's fault. But I'm afraid that I did not reemerge > sbcl with portage since it seemed to install as expected. > Using portage to emerge sbcl solved the problem for me. O.K., this makes sense. If you had installed SBCL with Paludis, then Maxima will fail regardless of the package manager, since SBCL's fasl files will have wrong mtimes. Only emerging SBCL with good timestamps will help. Which is what you observe. > What does PMS say about timestamps? See here: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=de6ee9c6ad50d4d130e9ad02f31bddced15293f4>
I have removed the timestamp workaround for sbcl for 1.2.26-r10 since portage has been fixed to preserve mtimes. I do not intend to put it back. Either use an older version of sbcl or use a package manager that preserves mtimes.
The hack is back, and I've bumped sbcl to 1.0.36-r1. The new ebuild uses EAPI 3, so the mtimes are preserved. I resolve the bug as FIXED. If anyone has any objection, reopen.
