Rebuilding sbcl change core timestamp, and maxima will not start until it is rebuilt with the new core. So a rebuild of sbcl should trigger a rebuild of maxima, after sbcl of course. Correct output with sbcl and maxima in sync : $ maxima Maxima 5.45.1 https://maxima.sourceforge.io using Lisp SBCL 2.1.5 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) _ Output when sbcl and maxima are not in sync : $ maxima fatal error encountered in SBCL pid 32064 tid 32064: core was built for runtime "localhost-portage-2021-06-02-12-38-22" but this is "localhost-portage-2021-06-22-14-46-31" Reproducible: Always Steps to Reproduce: 1. emerge maxima with sbcl use flag, ensure it start 2. rebuild sbcl 3. maxima won't start 4. rebuid maxima 5. maxima works again
There is no way to force a rebuild of maxima whenever SBCL is rebuilt. Perhaps instead we should hack the SBCL "build id" so that it is consistent between rebuilds of SBCL. The offending code is in SBCL's make-config.sh, which currently does echo '"'`hostname`-`id -un`-`date +%Y-%m-%d-%H-%M-%S`'"' > output/build-id.inc We could put something like ${PV} in there instead, and then have maxima rebuild whenever the subslot (0/${PV}) of SBCL changes.
Everything was fine in 5.44.0-r9, see the line DEP="dev-lisp/${LISP}:=" When the ebuild was completely re-written (5.44.0-r10), this := got missing. For all lisps, not just for sbcl. It should be restored for all lisps in LISP_DEPEND
(In reply to Andrey Grozin from comment #2) > Everything was fine in 5.44.0-r9, see the line > DEP="dev-lisp/${LISP}:=" > When the ebuild was completely re-written (5.44.0-r10), this := got missing. > For all lisps, not just for sbcl. It should be restored for all lisps in > LISP_DEPEND That's part of it, but := won't trigger a rebuild of maxima if the same version of SBCL is re-emerged. Also, cmucl, gcl, and clozurecl don't have subslots to make := meaningful, but maybe that's a shortcoming of those packages...
(In reply to Michael Orlitzky from comment #3) > Also, cmucl, gcl, and clozurecl don't have subslots to make := meaningful, > but maybe that's a shortcoming of those packages... At least for sbcl, clisp, ecls := is absolutely mandatory. When a user ungrades one of them, maxima must be recommpiled.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ad7de14616de70335cee40cf253d690f6c27a178 commit ad7de14616de70335cee40cf253d690f6c27a178 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2021-07-17 17:35:32 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2021-07-17 18:56:02 +0000 sci-mathematics/maxima: add slot:= operators for lisp dependencies. Maxima needs to be rebuilt when its lisp engine changes. Of the lisps supported by maxima, dev-lisp/sbcl, dev-lisp/ecls, and dev-lisp/clisp make use of subslots. This new revision adds := to the corresponding dependencies. This partially addresses bug 797574 by forcing rebuilds of maxima when sbcl is upgraded. Bug: https://bugs.gentoo.org/797574 Package-Manager: Portage-3.0.20, Repoman-3.0.2 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> .../maxima/{maxima-5.45.1-r1.ebuild => maxima-5.45.1-r2.ebuild} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Created attachment 724579 [details] sbcl-2.1.6.ebuild I've added the slot operators in maxima, and have attached an example ebuild for sbcl-2.1.6 that sets the "build id" to $PV.
Updating the summary as this is waiting on a change in dev-lisp/sbcl (comment #6) and is not really a maxima issue.
Another situation where this issue appeared: https://github.com/cschwan/sage-on-gentoo/issues/750
Andrey is now maintaining SBCL. All that remains to fix this is to ensure that the SBCL "build id" is $PV. The attached ebuild does this but is outdated. IIRC this is the relevant bit: # ...because we use our own build id. SBCL will refuse to run a # program (e.g. maxima) that was compiled against an SBCL with a # different build id. However, the build id that upstream generates # changes every time you re-build SBCL, even if nothing else has # changed. Thus rebuilding SBCL (likely a no-op) can disable your # copy of maxima. To avoid that, we use a build id that changes # only when our subslot changes, a trigger upon which we can # force rebuilds of our consumers. Was bug 797574. mkdir output || die echo "\"${PV}\"" > output/build-id.inc || die
Oh, you also need this BEFORE the line in my previous comment: # Don't echo random junk into output/build-id.inc... sed -e '/echo .* > output\/build-id\.inc/d' \ -i make-config.sh || die
From the given sbcl-2.1.6 ebuild the following is also needed after comment #9 # Also, don't run clean.sh during the build. First of all: why? # Second, because it clobbers the build-id.inc that we just created. sed -e '/sh clean\.sh/d' -i make-config.sh || die else build-id.inc is deleted.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=014d8209fe9d4e06bfeac40debc3dd762d59ae1c commit 014d8209fe9d4e06bfeac40debc3dd762d59ae1c Author: Andrey Grozin <grozin@gentoo.org> AuthorDate: 2023-08-06 11:15:02 +0000 Commit: Andrey Grozin <grozin@gentoo.org> CommitDate: 2023-08-06 11:15:02 +0000 dev-lisp/sbcl: bump to 2.3.7 Closes: https://bugs.gentoo.org/797574 Signed-off-by: Andrey Grozin <grozin@gentoo.org> dev-lisp/sbcl/Manifest | 2 + dev-lisp/sbcl/files/build-id-2.3.6.patch | 12 ++ dev-lisp/sbcl/sbcl-2.3.7.ebuild | 271 +++++++++++++++++++++++++++++++ 3 files changed, 285 insertions(+)