[armedbear-devel] r12666 breaks ASDF compilation on Linux

Alessio Stalla alessiostalla at gmail.com
Wed Jun 2 14:27:03 UTC 2010

2010/6/2 Alessio Stalla <alessiostalla at gmail.com>:
> 2010/6/2 Alessio Stalla <alessiostalla at gmail.com>:
>> 2010/6/2 Mark Evenson <evenson at panix.com>:
>>> On 6/1/10 9:50 PM, Knut Olav Bøhmer wrote:
>>>> Is there any workaround for this?
>>> You got a patch for my wrist?  ;}
>>> But seriously, I think disabling the JAR output translation by removing the
>>> reference(s) in ASDF:*OUTPUT-TRASLATIONS* with something like
>>> (setf asdf:*output-translations (list (remove
>>> #P"/___jar___file___root___/**/*.*" (first *output-translations*) :key #'car
>>> :test #'equal))
>>> would work.
>>> Alessio:  snow-0.3 fails to compile with 'sys:variable-information' not
>>> being found in 'snow.lisp', so I can't reproduce your error.  Maybe you need
>>> a new release from Snow trunk?
>> You're right: Snow 0.3 was still supposed to build with a patched
>> abcl, while trunk is not. However, I found out that the asdf problem
>> is only in the binary release of ABCL downloaded from the site, while
>> if I compile 0.20 myself it works, so r12666 is not the culprit. Since
>> you cited a Windows pathname, and I think Erik built those binaries on
>> Windows, is it possible that ASDF builds differently depending on the
>> OS, so that the resulting binary only works on that OS?
> Answering to myself, it appears indeed that the 0.20 binary contains a
> reference to Windows pathnames:
> CL-USER(1): *features*
> CL-USER(2): (require :asdf)
> CL-USER(3): (asdf::wrapping-output-translations)
> (#P"\\___jar___file___root___\\**\\*.*" (:USER-CACHE #P"**\\*.*"))
> (#P"jar:file:\\**\\*.jar!/**/*.*" (:FUNCTION
> This is presumably because pathnames are serialized to FASLs using
> their namestring, which is not necessarily the same string that was
> passed in with #P"...". Storing the user-provided string in the
> pathname and using that as a namestring if the pathname has not been
> destructively modified could solve this issue, if it's doable. Sigh,
> I'll have to reboot to Windows... ;)

I was able to fix the problem by moving the setting of the namestring
during the initialization of a pathname close to the beginning of the
init method, before / characters are replaced by \ on Windows. I
verified that on Windows I can load files regularly and that the
binary built on Windows works on Linux as well, but since pathnames
are foreign territory for me, I haven't committed the fix yet in case
someone points out some obvious mistake. Attached is a patch with my

-------------- next part --------------
A non-text attachment was scrubbed...
Name: windows-namestring.patch
Type: text/x-patch
Size: 795 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20100602/01eb947b/attachment.bin>

More information about the armedbear-devel mailing list