[Ecls-list] cl-launch and ecl, again

[Faré]

Dear Juanjo,

thanks a lot for your support.

I tried not one but two different ways of getting cl-launch to run with ECL:
* one (simplified from previous cl-launch thanks to the new asdf-ecl)
that calls the last builder directly and sometimes fails at runtime.
* one that fully relies on make-build and writes temporary asd files,
sometimes fails at compile-time.

With the first solution, ecl seems to always build an executable, but
sometimes this executable will fail during initialization, seemingly
trying to use variables before they have been defined, or otherwise
running initialization code out of order.

With the second solution, the linker seems to fail to find
initialization code that ecl expects, as in
1> (C::BUILDER :PROGRAM
#P"/home/fare/.cache/lisp-fasl/ecl-8.10.0__cvs_2008-07-12_18_54_-linux-pentium3/dev/shm/tmp/foo/cl-launch-6621-program"
:LISP-FILES (#P"/home/fare/.cache/lisp-fasl/ecl-8.10.0__cvs_2008-07-12_18_54_-linux-pentium3/dev/shm/tmp/foo/libcl-launch-6621-prefix.a"


              #P"/home/fare/.cache/lisp-fasl/ecl-8.10.0__cvs_2008-07-12_18_54_-linux-pentium3/dev/shm/tmp/foo/libclt-asd.a"


              #P"/home/fare/.cache/lisp-fasl/ecl-8.10.0__cvs_2008-07-12_18_54_-linux-pentium3/dev/shm/tmp/foo/libcl-launch-6621-program.a"))
/home/fare/.cache/lisp-fasl/ecl-8.10.0__cvs_2008-07-12_18_54_-linux-pentium3/dev/shm/tmp/foo/libclt-asd.a(ECLINITjQdZQR.o):
In function `init_lib_CLT_ASD':
/dev/shm/tmp/fare/ECLINITjQdZQR.c:40: undefined reference to
`_eclI7Z7omJ7_2XkTlSy'
collect2: ld returned 1 exit status
An error occurred during initialization:
(SYSTEM "gcc -o
\"/home/fare/.cache/lisp-fasl/ecl-8.10.0__cvs_2008-07-12_18_54_-linux-pentium3/dev/shm/tmp/foo/cl-launch-6621-program\"
-L\"/usr/local/stow/ecl/lib/\" \"/dev/shm/tmp/fare/ECLINITUeSclS.o\"
\"/home/fare/.cache/lisp-fasl/ecl-8.10.0__cvs_2008-07-12_18_54_-linux-pentium3/dev/shm/tmp/foo/libcl-launch-6621-prefix.a\"
\"/home/fare/.cache/lisp-fasl/ecl-8.10.0__cvs_2008-07-12_18_54_-linux-pentium3/dev/shm/tmp/foo/libclt-asd.a\"
\"/home/fare/.cache/lisp-fasl/ecl-8.10.0__cvs_2008-07-12_18_54_-linux-pentium3/dev/shm/tmp/foo/libcl-launch-6621-program.a\"
  -lecl -lpthread -ldl  -lm   -lgc -lgmp") returned non-zero value 1.

This might actually be the same bug, whereas some initialization
functions are missing but expected for asdf systems, except that in
one case some introspection routine just skips over those that were
forgotten, but the linker catches them statically.

If you're interested, you can try for yourself.

 mkdir /tmp/foo
 cd /tmp/foo
 wget http://fare.tunes.org/files/cl-launch/cl-launch_2.09.sh
 apt-get install clisp gcl gclcvs cmucl sbcl
 ./cl-launch_2.09.sh -l 'ecl' -B tests

Adding 76 as an argument after tests will start directly at the first
test that borks, which you can directly invoke this way:
 ./cl-launch_2.09.sh -B redo_test sh ecl exec noupdate dump noinc system noinit

You have a full log in tests.log, which can be made more verbose by
uncommenting the ;#+ecl line towards the bottom of cl-launch.

Note that I left the second implementation of build-and-dump wired in,
but you may switch implementation of build-and-dump by switching which
is correctly named and which is named xxx-build-and-dump.

> Yes, a lot of things have changed, fixing design errors and adding new
> functionality to support building monolithic systems that coexist with
> non-monolithic ones, avoiding name collisions and many other things
> that made the previous asdf:make-build of little use.
I'm glad this happened. But it looks like there are still bugs, and I
hope that with cl-launch it will become easier to detect and squash
those bugs, as the same programs are run with various implementations.

>> At one point, I was having ECL reusing objects from a previous
>> compilation and was confused. At this point, I'm befuddled as it dies
>> with the uninformative error message:
>> ;;; Warning: COMPILE-FILE warned while performing #<ASDF:COMPILE-OP
>> NIL 168542448> on
>> #<ASDF:CL-SOURCE-FILE "header" "cl-launch-prefix" 168378656>.
>> but no warning is printed. If I try to insert a break after that
>> happens, it also dies.
>
> This is a problem with ASDF itself, not really the ECL environment nor
> our extensions. ASDF captures all compiler conditions (i.e. errors and
> warnings) and thus will prevent you from entering the debugger. I do
> not remember whether there are options to enter the debugger from
> ASDF, but you may try setting c::*compiler-break-enable* to T before
> building anything
>
Thank you for this tip. However, it didn't help. I never got into the
debugger and never got a backtrace :-(

I think the unprinted warning is about the redefinition of functions
already loaded by cl-launch (as cl-launch tries to compile itself as a
prefix to what follows), but I am not sure how to confirm the
hypothesis.

>> Also, to save me a bit of work, what is the name of the file created
>> by (asdf::make-build :cl-launch-program :type :program) ?
>
> I cannot tell you just like that, without knowing the platform and
> your configuration settings. But the ANSI standard function
> COMPILE-FILE-PATHNAME exists for this reason. Just pass it the same
> type as you would pass to make-build.
>
Well, as previously reported (two years ago, when I first released
cl-launch support for ecl - we don't get any younger, do we?),
COMPILE-FILE-PATHNAME is not compliant, because it accepts a set of
parameters different from COMPILE-FILE, whereas the standard mandates
that any extension supported by COMPILE-FILE must be supported by
COMPILE-FILE-PATHNAME. I have to call the former with :type :object
and the latter with :system-p t. That's most confusing, and a remnant
from the ancient history of ECL, but I got around it with ugly #+ecl
in cl-launch.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The ultimate result of shielding men from the effects of folly is
to fill the world with fools. -- Herbert Spencer