bundle-test fails on ABCL on Mac OS X Lion

Bug #1207073 reported by Robert P. Goldman
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ASDF
Confirmed
Undecided
Unassigned
Armed Bear Common Lisp
New
Undecided
Mark.Evenson

Bug Description

Checking the output of the test I find:

TEST ABORTED: Loadable FASL not found for '#P"/Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl"' in '#P"jar:file:/Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl!/bundle-1--system._"'
Above backtrace due to this condition:
Loadable FASL not found for '#P"/Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl"' in '#P"jar:file:/Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl!/bundle-1--system._"'
Script failed

This is ASDF 3.0.2.2

Revision history for this message
Faré (fahree) wrote :

Works for me on ABCL 1.2.1, Ubuntu 12.04.2 LTS, Linux 3.2.5 x86_64.

I don't understand this part of ABCL, but your pathname has a jar host/device, which is obviously the wrong thing for a fasl cache that is not precompiled. Something might be wrong in your output-translations configuration.

Revision history for this message
Robert P. Goldman (rpgoldman) wrote : Re: [Bug 1207073] Re: bundle-test fails on ABCL on Mac OS X Lion

I ran this out of make test, which should be controlling the output-translations, shouldn't it? I mean, there shouldn't be anything about my local ASDF configuration that's bleeding into these tests.

I suppose it's possible that the Mac Ports version of ABCL, which I'm running, is somehow misconfigured. But if that's at fault, it would be good to know.

Any suggestions for detecting the configuration problem would be welcom.

Revision history for this message
Robert P. Goldman (rpgoldman) wrote :

I investigated a little further: that jar file handle does seem to be correct -- there is a file called bundle-1--system.abcl, and it is a jar file, according to "jar tf"

Loadable FASL not found for '#P"/Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl"' in '#P"jar:file:/Users/rpg/lisp/asdf/build/fasls/abcl-1.2.1-fasl42-macosx-x64/asdf/test/test-asdf/bundle-1--system.abcl!/bundle-1--system._"'.

I have not been able to tell from ABCL's backtrace what file it is trying to open. If anything, the error message suggests that it's trying to look for the jar file inside its own contents.

here are the contents of that jar file:

 $ jar tf bundle-1--system.abcl
file3/
file3/__loader__._
file1/
file1/__loader__._

AFAICT this happens trying to do the load-fasl-op on bundle2, which depends on bundle1.

Revision history for this message
Faré (fahree) wrote :

At this point, we need an ABCL hacker who understands jar files to step in.

For the record, it works for me using ABCL 1.1.0 on Linux x64, Sun JVM 1.6.0_27.

Revision history for this message
Faré (fahree) wrote :

Also works for me using ABCL 1.2.1 on Linux x64, Sun JVM 1.6.0_27.

Revision history for this message
Robert P. Goldman (rpgoldman) wrote :

This test is turned off on Mac + ABCL for now, pending support from the ABCL devels.

Changed in armedbear:
assignee: nobody → Mark.Evenson (evenson-not-org)
Revision history for this message
Mark.Evenson (evenson-not-org) wrote :

The problems with BUNDLE-OP were triaged to problems in ABCL's use of :WILD-INFERIORS on directories referred to via symlinks. OS X symlinks /private/tmp to /tmp which was why the problem was mysteriously not working only on this platform.

This error was fixed when I [finished re-working DIRECTORY to default to :RESOLVE-SYMLINKS as nil][r14624] which currently exists in abcl-1.3.0-dev.

If you wish to conditionalize on the fix, the form

    (not (second (third (sys::arglist 'directory))))

should return T for versions of ABCL that work with BUNDLE-OP on OS X.

[r14624]: http://abcl.org/trac/changeset/14624

Revision history for this message
Robert P. Goldman (rpgoldman) wrote :

Mark.Evenson wrote:
> The problems with BUNDLE-OP were triaged to problems in ABCL's use of
> :WILD-INFERIORS on directories referred to via symlinks. OS X symlinks
> /private/tmp to /tmp which was why the problem was mysteriously not
> working only on this platform.
>
> This error was fixed when I [finished re-working DIRECTORY to default to
> :RESOLVE-SYMLINKS as nil][r14624] which currently exists in
> abcl-1.3.0-dev.
>
> If you wish to conditionalize on the fix, the form
>
> (not (second (third (sys::arglist 'directory))))
>
> should return T for versions of ABCL that work with BUNDLE-OP on OS X.
>
> [r14624]: http://abcl.org/trac/changeset/14624
>

Thanks, Mark. Will you please pull a copy of ASDF -- the new 3.1.0.65 I
pushed with these checks -- and see if it passes test-bundle on your
development copy of ABCL?

I have checked that it correctly refuses to do the bundle op on Mac OS X
when unsupported; would like to know that the operation is executed and
works correctly where it's supported.

Changed in asdf:
status: New → In Progress
Revision history for this message
Robert P. Goldman (rpgoldman) wrote :

In the next version of ASDF, we will correctly identify whether or not BUNDLE-OP is supported on Mac OS X + ABCL.

When it's used we will either raise an error, if it's unsupported, or should run correctly (based on Mark's reports about tests on the development version of ABCL -- thanks, Mark!).

Changed in asdf:
status: In Progress → Fix Committed
Revision history for this message
Robert P. Goldman (rpgoldman) wrote :

I'm going to actually mark this as fix not committed. The fact is that ABCL + bundle op don't work; we just no longer test them. This will have to be kicked out into a following release when we can get more support from the ABCL developers.

Changed in asdf:
status: Fix Committed → Confirmed
milestone: none → version4
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.