Created attachment 696186 [details] compressed log Tried to emerge maxima-5.44.0-r6 on ~amd64 with USE="sbcl gcl clozurecl64 ecls clisp"
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d165604ed61363129ae90021ba998bde968ab2a1 commit d165604ed61363129ae90021ba998bde968ab2a1 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2021-03-30 11:19:21 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2021-03-30 12:40:52 +0000 sci-mathematics/maxima: drop eutils.eclass and duplicate launcher. Upstream provides its own xmaxima launcher now, so the one that we were (attempting to, since I borked it during the EAPI=7 bump) create is no longer necessary. This commit drops the duplicate icon, and the use of eutils.eclass which no longer serves any discernable purpose. Closes: https://bugs.gentoo.org/779325 Package-Manager: Portage-3.0.13, Repoman-3.0.2 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> .../maxima/{maxima-5.44.0-r6.ebuild => maxima-5.44.0-r7.ebuild} | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
Ugh, this new firefox URL bar selection behavior is FUCKING INFURIATING. I fixed the other bug, not this one, but I have to copy/paste twice now.
I can't set USE=gcl here because all versions of dev-lisp/gcl fail to compile no matter what I do. Does the problem still exist for you with USE="-gcl"? If so, at least that means I can try to troubleshoot it without first having to fix gcl.
This looks like the first important error message: ; - Loading binary file "binary-ccl64/sloop.lx64fsl" ;Loading #P"binary-ccl64/sloop.lx64fsl"... ; - Compiling module "declarations" ; - Compiling source file ; "/var/tmp/portage/sci-mathematics/maxima-5.44.0-r6/work/maxima-5.44.0/src/lmdcls.lisp" ;Compiling "/var/tmp/portage/sci-mathematics/maxima-5.44.0-r6/#P"/var/tmp/portage/sci-mathematics/maxima-5.44.0-r6/work/maxim#P"/var/tmp/portage/sci-mathematics/maxima-5.44\ .0-r6/work/maxima-5.44.0/lisp-utils/defsystem.lisp" a-5.44.0/lisp-utils/defsystem.lisp" ? ? ("../src/" "./" (MAKE::HOME-SUBDIRECTORY "lisp/systems/") "/usr("../src/" "./" (MAKE::HOME-SUBDIRECTORY "lisp/systems/") "/usr/local/lisp/Registry/") /local/lisp/Registry/") ? ? #P"/var/tmp/portage/sci-mathematics/maxima-5.44.0-r6/work/maxim#P"/var/tmp/portage/sci-mathematics/maxima-5.44.0-r6/work/maxima-5.44.0/lisp-utils/make-depends.lisp" a-5.44.0/lisp-utils/make-depends.lisp" ? ? > Error: No such file or directory : "ccl64-depends.mk.tmp" > While executing: CCL::MAKE-FILE-STREAM, in process listener(1). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > cat ccl64-depends.mk.tmp | sed -e "s#\\\\#/#g" > ccl64-depends.mk
Created attachment 696462 [details] Compressed log Strange observations: 1. USE="sbcl cmucl64 ecls clisp" succeeds 2. USE="gcl -sbcl" succeeds 3. USE="gcl sbcl" fails in the same way, see thr attached file. The first error message is make[1]: *** [Makefile:1380: tools/sys-proclaim.lisp] Error 1 So, each lisp separately, and some combinations succeed. Some combinations fail. Looks like some unwanted interaction of different lisp builds in the ebuils, whareas they should be independent (at least logically). Seems to be a parallel build error (they are often intermittant). In the old maxima ebuild I added -j1 exactly because this kind of intermittent failures happend before this.
No, with -j1 USE="sbcl gcl cmucl64 ecls clisp" still fails with Clozure Common Lisp Version 1.12 LinuxX8664 For more information about CCL, please see http://ccl.clozure.com. CCL is free software. It is distributed under the terms of the Apache Licence, Version 2.0. ? for l in clisp sbcl gcl ccl64 ccl64 ecl; do for d in / /numerical /numerical/slatec; do /bin/mkdir -p binary-$l$d; done; done for l in clisp sbcl gcl ccl64 ccl64 ecl; do for d in / /numerical /numerical/slatec; do /bin/mkdir -p binary-$l$d; done; done for l in clisp sbcl gcl ccl64 ccl64 ecl; do for d in / /numerical /numerical/slatec; do /bin/mkdir -p binary-$l$d; done; done rm: cannot remove 'binary-gcl': Directory not empty make[1]: *** [Makefile:1380: tools/sys-proclaim.lisp] Error 1 make[1]: *** Waiting for unfinished jobs.... make[2]: Leaving directory '/var/tmp/portage/sci-mathematics/maxima-5.44.0-r7/work/maxima-5.44.0/src'
-j1 USE="sbcl gcl" fails with echo ' (load "../lisp-utils/defsystem.lisp") (mk:add-registry-location "../src/") (funcall (intern (symbol-name :operate-on-system) :mk) "maxima" :compile :verbose t) (sb-e xt:quit)' | "sbcl" --noinform --noprint && echo '(load "../lisp-utils/defsystem.lisp") (mk:add-registry-location "../src/") (funcall (intern (symbol-name :operate-on-syst em) :mk) "maxima" :load :verbose t) (sb-ext:save-lisp-and-die "binary-sbcl/maxima.core") (sb-ext:quit)' | "sbcl" --noinform --noprint rm: cannot remove 'binary-gcl': Directory not empty make[1]: *** [Makefile:1380: tools/sys-proclaim.lisp] Error 1 make[1]: *** Waiting for unfinished jobs....
It's starting to look like USE=gcl is the issue when combined with any other lisp implementation. This may even be an upstream bug. I really need to figure out how to get some version of GCL installed so that I can test.
gcl succeeds gcl + clozurecl64 succeeds gcl + sbcl fails echo ' (load "../lisp-utils/defsystem.lisp") (mk:add-registry-location "../src/") (funcall (intern (symbol-name :operate-on-system) :mk) "maxima" :compile :verbose t) (sb-e xt:quit)' | "sbcl" --noinform --noprint && echo '(load "../lisp-utils/defsystem.lisp") (mk:add-registry-location "../src/") (funcall (intern (symbol-name :operate-on-syst em) :mk) "maxima" :load :verbose t) (sb-ext:save-lisp-and-die "binary-sbcl/maxima.core") (sb-ext:quit)' | "sbcl" --noinform --noprint rm: cannot remove 'binary-gcl': Directory not empty make[1]: *** [Makefile:1380: tools/sys-proclaim.lisp] Error 1 make[1]: *** Waiting for unfinished jobs.... gcl + ecls fails echo ' (load "../lisp-utils/defsystem.lisp") (mk:add-registry-location "../src/") (funcall (intern (symbol-name :operate-on-system) :mk) "maxima" :compile :verbose t) (buil d-maxima-lib) (ext:quit)' | ecl -norc rm: cannot remove 'binary-gcl': Directory not empty make[1]: *** [Makefile:1380: tools/sys-proclaim.lisp] Error 1 make[1]: *** Waiting for unfinished jobs.... gcl + clisp fails echo ' (load "../lisp-utils/defsystem.lisp") (mk:add-registry-location "../src/") (funcall (intern (symbol-name :operate-on-system) :mk) "maxima" :compile :verbose t)' > cl isp-command.lisp clisp -norc -q clisp-command.lisp rm: cannot remove 'binary-gcl': Directory not empty make[1]: *** [Makefile:1380: tools/sys-proclaim.lisp] Error 1 make[1]: *** Waiting for unfinished jobs....
In the successful combination gcl + clozurecl64, the corresponding fragment of the log is echo '(load "../lisp-utils/defsystem.lisp") (mk:add-registry-location "../src/") (funcall (intern (symbol-name :operate-on-system) :mk) "maxima" :compile :verbose t) (system::quit)' | gcl GCL (GNU Common Lisp) 2.6.12 ANSI Fri Apr 22 15:51:11 UTC 2016 ... I.e., this echo '(load "../lisp-utils/defsystem.lisp") (mk:add-registry-location "../src/") (funcall (intern (symbol-name :operate-on-system) :mk) "maxima" :compile :verbose t) (system::quit)' is piped to gcl. The same is, of course, true for gcl-only build. In the failed combinations, this echo is piped to another lisp: sbcl, ecl, or is saved to a file given to clisp. Intetresting. Why in the gcl+clozurecl64 case the build system decides to send this echo output to gcl, but in the cases gcl+sbcl, gcl+ecls, gcl+clisp - to the non-gcl lisp?
Well this is interesting. I managed to hack on gcl enough to get it to build. Afterwards I added "-d -j1" to the "emake" line in the maxima ebuild, and... it compiled successfully with USE="sbcl gcl"! The search continues...
Created attachment 696897 [details] maxima-5.44.0-r7.log.xz Here's by build log for comparison...
That's with the unmodified ebuild, and with more lisps enabled. Not really surprising, but in the same lines that's giving you problems, I see the command being piped to "gcl" as expected. I'm on amd64 too but my PC is ancient. Nevertheless you'd think that -j1 would sort out any parallelism issues, unless asdf does its own?
Is this still happening with maxima-5.45.1-r1? I was completely defeated by this problem so I'm curious if it persists.
Praying that this resolved itself because I never had any success with it.
