bundle-test fails on ABCL on Mac OS X Lion

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.

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.

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.

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.

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

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

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

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.

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!).

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.