[armedbear-devel] r12666 breaks ASDF compilation on Linux

[Alessio Stalla]

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*
> (:JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :UNIX :LINUX :CDR6)
>
> CL-USER(2): (require :asdf)
> ("CLOS" "PRINT-OBJECT" "FORMAT" "ASDF")
>
> CL-USER(3): (asdf::wrapping-output-translations)
> (:OUTPUT-TRANSLATIONS :INHERIT-CONFIGURATION
> (#P"\\___jar___file___root___\\**\\*.*" (:USER-CACHE #P"**\\*.*"))
> (#P"jar:file:\\**\\*.jar!/**/*.*" (:FUNCTION
> ASDF::TRANSLATE-JAR-PATHNAME)) :ENABLE-USER-CACHE)
>
> 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
fix.

Bye,
Alessio
-------------- 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>