ECL Binary Compilation fails when grovel is involved e.g. (dependency on iolib)

[Juergen Bickert]

asdf commit culprit
 a9c22442 | * Move node visit information from plan to session

Further information:
https://gitlab.com/embeddable-common-lisp/ecl/issues/414

[Juergen Bickert (kaiserprogrammer)]

Not only iolib is affected, the same happens on a dependency to osicat.
asdf versions before that commit work, and since that commit this is the error for osicat:

  Condition of type: SIMPLE-TYPE-ERROR
  Not a condition type: CFFI-GROVEL::MISSING-DEFINITION
  No restarts available.

Again something is undefined. Which indicates a different loading order.

[Faré (fahree)]

Do you have a machine on which to test that?

[Faré (fahree)]

Also, what version of CFFI are you using?

[Juergen Bickert (kaiserprogrammer)]

I have the most recent quicklisp distribution, but I have tested it with cffi versions 0.19 and 0.18 .

I am compiling it on my workstation (x86_64) and on a local arm (32-bit) processor.

[Faré (fahree)]

OK, I installed Debian in a chroot and could reproduce your issue with its ecl 16.1.2.

The issue is that on ECL, by design, dependencies that are in your defsystem-depends-on are NOT included in your depends-on by default, and therefore are not included in the program linked by program-op. Users of image-based Lisps do not have this issue, because everything is loaded in their image anyway as part of he defsystem-depends-on. But for correct operation on ECL and MKCL, you need to explicitly include in your depends-on the dependencies that you need loaded at runtime.

So this looks like ASDF behaves correctly as designed, whereas iolib should explicitly include whichever subset of its defsystem-depends-on it needs at runtime in its depends-on.

[Faré (fahree)]

Maybe defsystem-depends-on should make it easy for the ddo dependency to declare matching runtime dependencies on depends-on.

[Juergen Bickert (kaiserprogrammer)]

I guess it's then not possible for defsystem-depends-on to add those dependencies onto depends-on machinery for ecl.

[Faré (fahree)]

Everything is possible. Maybe this should be done for greater compatibility with other implementations. Although my interaction with ECL maintainers suggests that they like to minimize the amount of things linked in (up to not including ASDF itself), so I'm not sure how popular that change would be.

[Faré (fahree)]

In 3.3.2, there are patches that fix bundle operations when upgrading from ECL's asdf. Maybe they fix that issue. Or not.