asdf monolithic-lib-op for ecl builds .a's without an init-name function

[Jesse Off]

Trying to use the latest asdf 3.3.4 with ecl 20.4.24 on a monolithic-lib-op but it no longer generates the init_lib_FOO__ALL_SYSTEMS function it did on previous versions. Instead there seems to be a randomly generated function similar to, e.g. init_lib__ECLTNST0W88_HJLH5Z41

It looks like the ecl bundled asdf's (asdf:make-build) function is the only way to generate .a's with specifiable init-names.

[Faré (fahree)]

I admit I haven't been following this closely, but my understanding is that recent versions of ECL changed the way that initialization functions work, and that this may be the new way of doing business. Please check with ECL implementers and confirm what ASDF should be doing and whether it isn't doing the right thing.

Do the ASDF tests pass or fail for you?

[Jesse Off (jesseoff)]

This is the closest relevant line from the latest CHANGELOG file:

- asdf:make-build accepts ~:init-name~ argument for libraries
this allows specifying human-memorable initialization function name to call
in C code

Also it seems all their latest documentation seems still to be specifying `(asdf:make-build)` as the way to build libraries from .asd systems. If I use the make-build function on the 3.3.4 asdf, besides complaining about using a deprecated interface, I get an unuseable .a that seems to have ignored my :init-name arg and generated a .a with the random init func name. At least the bundled asdf 3.1.8.8 included in this new April 2020 ecl honors the :init-name.

I did just post this issue also to ecl too:
https://gitlab.com/embeddable-common-lisp/ecl/-/issues/603

I'm using the single asdf.lisp bundling of asdf 3.3.4 and not sure how to run tests from that.

[Faré (fahree)]

My recollection is that we changed the behavior of ASDF at the request of ECL maintainers, who told us the protocol had changed on the ECL side.

Please get an official answer from ECL maintainers as to what ASDF's behavior should be, and/or provide a patch that you can confirm works with the latest version of ECL as well as earlier releases if possible using conditional compilation.

[Jesse Off (jesseoff)]

It sounds like they found a corner case with the automatically generated humand readable init-name's they used in the past with unspecified init-name options so they've removed that functionality. The corner case had to do with systems named foo/base and bar/base both end up generating the same auto :init-name. It seems the solution was to simply no longer generate auto init-names.

It would seem that asdf should be modified to allow :init-name in the system definition build-args and use it even for lib-op's. It looks like there was an attempt to put that in asdf using :build-args, but its only enable for creating executables and not libraries ("programp" predicate for operation true) The init-name option is most needed for shared/static libraries anyway as C integrators need to know it to call it at the appropriate time.

[Faré (fahree)]

Looks like you might be the best person to provide a patch. Can you make sure it works on all recent versions of ECL, and include a test in our test suite?

[Jesse Off (jesseoff)]

What I've done locally is add a :init-name option for the :class program-system defsystem that seems to be what you've used to accumulate alot the ecl specific stuff. This is then passed to the c:build-static-library or c:build-shared-library ecl functions, but not to the program executable targets, where it doesn't really make sense.

If this is agreeable I'll try my hand and giving you a proper patch and test case against the non-bundled lisp sources. I'm not sure I'm not missing something obvious as to the proper way to do this though.

FWIW, the :class program-system line seems a little weird and surprising to me for building libraries, but there seems to have been some purposeful initiative towards that in a comment around the defclass monolithic-bundle-op. Also that the machinery for building libraries in ecl is in a function named create-image, with a docstring implying its only for building executables is surprising also.

[Faré (fahree)]

Also, we recently moved to https://gitlab.common-lisp.net/asdf/asdf as our main issue tracking and patch merging platform.

You can also use the git history to see how our code was before the latest change.

[Jesse Off (jesseoff)]

There seems to be a problem with your gitlab service in accepting new registrations. I jump through the hoops on IRC only to be told I'm blocked and must contact the administrator.

Anyway, attached is a test case + patch for a fix.

Old ECLs would create a human-readable (ish) initialization function when unspecified, new 20.4.24 ECL doesn't, names are now unavoidably completely random. There seems to be some recent changes applied to attempt to fix this, but was conditional on the operation being for program target, for which :init-name makes no sense.

I don't think theres any way to be backward compatible with the old ecl behavior on new ecls, so it seems new version ecl users will have no choice but to specify :class program-system and :extra-build-args (:init-name "init_foo") into their .asd files for monolithic-lib-op to work.

There may be some future coding cleverness in attempting to recreate the old compute-init-name within asdf when the :init-name is not specified in the .asd :extra-build-args. That way, it would still be possible to run monolithic-lib-op on .asd defsystems that aren't :class program-system and have a 95% chance the system name can be a human and C compatible function init name.

[Jesse Off (jesseoff)]

There seems to be a problem with your gitlab service in accepting new registrations. I jump through the hoops on IRC only to be told I'm blocked and must contact the administrator.

Anyway, attached is a test case + patch for a fix.

Old ECLs would create a human-readable (ish) initialization function when unspecified, new 20.4.24 ECL doesn't, names are now unavoidably completely random. There seems to be some recent changes applied to attempt to fix this, but was conditional on the operation being for program target, for which :init-name makes no sense.

I don't think theres any way to be backward compatible with the old ecl behavior on new ecls, so it seems new version ecl users will have no choice but to specify :class program-system and :extra-build-args (:init-name "init_foo") into their .asd files for monolithic-lib-op to work.

There may be some future coding cleverness in attempting to recreate the old compute-init-name within asdf when the :init-name is not specified in the .asd :extra-build-args. That way, it would still be possible to run monolithic-lib-op on .asd defsystems that aren't :class program-system and have a 95% chance the system name can be a human and C compatible function init name.

[Jesse Off (jesseoff)]

Turns out one of the other tests fail with this (ecl-make-image) now. Looks like even program-op does a behind-the scenes c::build-static-library which causes the duplicate ld-flags. Fixing shortly.

[Jesse Off (jesseoff)]

This passes all tests.

[Faré (fahree)]

I had to click on a link sent by email to (re)activate my gitlab account.

If you can't make it work on both, better to make it work on the new one.

Why can't it just work by default without user input?

[Faré (fahree)]

Let's move this discussion to https://gitlab.common-lisp.net/asdf/asdf/-/issues/38 and mark it here as "Won't Fix"