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 <even...@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/>

_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to