[MacPorts] #37214: Maxima not playing well with SBCL 1.1.2

[Kevin Reid]

On Dec 6, 2012, at 1:11, Joshua Root wrote:

> On 2012-12-6 19:35 , Ryan Schmidt wrote:
>> 
>> On Dec 6, 2012, at 01:22, Mark Evenson <evenson at panix.com> wrote:
>> 
>>>> Comment (by jmr@…):
>>>> 
>>>> IIRC it's necessary to increment maxima's revision every time sbcl's
>>>> version is updated.
[...]
>> If maxima must be built against the current version of sbcl, which is what jmr's comment makes it sound like, then I don't think there's any workaround.
[...]
> Yeah, I don't know *why* it needs to be built against the same version
> it runs against. I just remembered <https://trac.macports.org/ticket/27696>.


The build process of Maxima writes a memory image of SBCL with Maxima loaded in it (so that startup consists of mmap'ing the image rather than loading a lot of definitions). This image is only compatible with the same version of the SBCL runtime.

IMO, the least-invasive appropriate fix would be to treat this just like the “broken binary” situation (but I don't know if that's feasible to do in MacPorts) -- detect the mismatch and auto-rebuild maxima.

Another possibility is to change maxima so that it uses SBCL's ability to dump an image together with the runtime, forming a large but standalone executable. This should be pretty much setting one extra option for the image (the relevant function is called save-lisp-and-die, see <http://www.sbcl.org/manual/Saving-a-Core-Image.html>) and convincing the Maxima build process to treat that output itself as the executable rather than launching SBCL using it.

Note that while this would eliminate the necessity to rebuild, it would arguably be surprising in that maxima would be forever stuck with the version of SBCL it was originally built against, rather than the current installed version.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>