Oddities in ECL tests on Linux

[Faré]

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 at 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.
>
>
>