Example in ECL repository for static link

Daniel Kochmański daniel at turtleware.eu
Tue Jun 20 07:00:47 UTC 2023


Hey Thomas,



------- Original Message -------
On Monday, June 19th, 2023 at 5:34 PM, Thomas Teixeira <thomas.teixeira at startmail.com> wrote:


> Hi !
> Thanks for ECL, I've been learning CL for the past weeks and it's my favorite
> implementation so far ! Would love to contribute one I've the required skills
> :))

That sounds great :)

> 
> I'm trying to create a small script that'll allow users to recreate a mail
> thread inside a virtual maildir box. I would like to use ECL for that script but
> the project which this script will belong to ([fruitslegumes][1]) is focused on
> using no dependencies.

Does libc count as a dependency? Currently ECL links dynamically against libc even
for static builds. There are no technical reasons why it couldn't link statically
against libc (and we want to allow that), but currently flags in multiple places
simply assume a dynamic link.

> 
> Because of this constraint, I only ever used POSIX-shell/C99 to build those
> scripts
> I would love to use ECL as programs can be compiled down to machine code, which
> can be `upx`-ed, but users would have to install their ecl package.
> 
> I managed to statically link libecl with a simple script, but it gets harder for
> me when trying with the example-with-dep program.
> I saw in a previous thread of this mailing list that statically linking ECL
> makes asdf unusable. Is that still the case ?

It is not that ASDF is unusable when we link statically. There are a few ramifications
though. I'll elaborate a little here about FASL files in ECL:

> Would it be possible to either provide an example (if what i'm asking is even
> possible) or talk in more depth about ecl being statically linked ?

The fasl file created by ECL is a shared object that is linked dynamically against
libecl.so. If it were a static object, then each and every fasl would need to carry
whole ECL runtime statically linked. That's not a sound solution.

Now, regarding using ASDF in static builds. When the C compiler is not installed
(either not build with ECL, or (ext:install-bytecodes-compiler) was called), then
files compiled by ECL are in FASC format, that is the bytecode. Such bytecode may
be loaded with statically linked ECL. ASDF should work fine with FASC files, although
some libraries may assume the C compiler, so not all software will work with it.

If you want to have ASDF statically linked in the resulting binary, you need to specify
that when building ECL. For example ./configure --disable-shared --with-asdf=builtin .

There's also that you may compile your lisp source code along with ECL and statically
link it (that would be somewhat similar to the example with deps), although there is
no explicit support for ASDF. To specify files that should be compiled and linked with
ECL you may specify the flag --with-extra-files.

As you can see, static linking is somewhere in the ballpark of what ECL can do, but
it is not well supported. I'm working on some compiler improvements to allow easier
cross compilation and other similar things and hope that during that work I'll also
improve the support for static builds (although that is not the main focus).

I hope that this explanation is at least partly satisfactory.

> 
> Regards,
> Thomas.

Best regards,
Daniel


--
Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
TurtleWare - Daniel Kochmański      | www.turtleware.eu

"Be the change that you wish to see in the world." - Mahatma Gandhi




More information about the ecl-devel mailing list