I can reproduce the issue. When running the image, it looks like uiop failed to be included, even though we explicitly depend on it. I believe this is a combination of one or several of the below:
1- The way that ASDF, since 3.3 or so, refuses to read uiop.asd unless it's strictly newer than ASDF 2- The fact that this test configures an empty source-registry to begin with, so it can't load either ASDF or UIOP from source anyway, it seems 3- The fact that this ECL, unlike e.g. MKCL and SBCL, doesn't provide uoip as a linkable "require" module 4- Somehow, bundle's failure by to fall back to loading the entire ASDF when UIOP isn't present alone, yet needed. 5- Somehow, bundle's failure to link to the libasdf.a provided by ecl. 6- The fact that ECL, being linking-based rather than load-based, doesn't preserve ASDF from the builder's image.
All in all, it's probably a bug in bundle.lisp.
THAT SAID, I just recompiled ECL after many months (years?), using ECL (Embeddable Common-Lisp) 16.1.3 (git:ba6e6ddde780c097918673f16c7aba05f354d022) on Linux amd64 Ubuntu, and trying to (require :asdf) (asdf:load-system :asdf) from the command line in the ecl executable would cause the stack to blow up (and eventually segfault if you keep choosing the restart to continue with more stack). On the other hand, I can load the asdf build and test system can create a bootstrap asdf.fas that can be loaded with no problem. SO, I'm not excluding an ECL bug, either. — Obviously, some things are wrong with ECL, too. I still bet there's a bug in ASDF.
Sorry, I have few cycles to spare for Common Lisp these days.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Amateur bureaucrats are often even worse than professional bureaucrats. — John McCarthy
On Thu, Aug 23, 2018 at 4:22 PM Robert Goldman rpgoldman@sift.info wrote:
My Jenkins job is failing to test ECL successfully. What's interesting is that it looks like the tests are successful, but the checker is failing. Here's what I see in the transcript:
These two expressions fail comparison with EQUAL: (UIOP/UTILITY:NEST (LISP-INVOCATION/LISP-INVOCATION:INVOKE-LISP :IMPLEMENTATION-TYPE (LISP-INVOCATION/ALLEGRO-VARIANTS:CURRENT-LISP-VARIANT) :CROSS-COMPILE NIL :IMAGE-PATH (UIOP/FILESYSTEM:NATIVE-NAMESTRING ASDF-TEST::IMG) :CONSOLE T :EVAL "(uiop:restore-image :entry-point 'hello:entry-point :lisp-interaction nil)" :RUN-PROGRAM-ARGS '(:OUTPUT :LINES :ERROR-OUTPUT T))) evaluates to ("No restarts available." "" "Top level in: #<process TOP-LEVEL>." "> ") '("hello, world") evaluates to ("hello, world")
Oddly, when I try to run this at the command line, ECL throws to the interactive debugger on various signals and I have to restart it, before
make test l=ecl
will terminate successfully.
I think I have seen this before, and it may be that ECL implicitly assumes that there will be some kind of C compilation tool chain present that I don't have, but I'm not sure about that.
Suggestions for debugging would be welcom.