Le 24 août 2017 10:18 AM, "Daniel Kochmański" <daniel@turtleware.eu> a écrit :

you can build ECL as a static library and statically link with it. You have to pass --disable-shared flag at configure time. Then you will have libecl.a and statically linked ecl binary. This option isn't well tested but it works as far as I can tell. You may want to link your library with other static libs, like libcmp.a etc, which will be installed in DESTDIR/lib/ecl-16.1.3/ .

Thanks! I gave in and added ecl itself as a submodule of my application, and am now building it as part of the normal build. It's not that bad.

Note, that you won't be able to load natively compiled FAS files (only bytecompiled FASC) at runtime, only to compiled with build libraries. That could be fixed and is somewhere on my list (though it has a low priority).

This... actually makes it kind of painful. It means ASDF doesn't work. So I have to load the dependencies myself, compile them and load them file after file, recursively (bottom first).

A bit too painful for my taste, and I went with bundling the shared library with the app in the end, in order to keep some sanity. I'm not familiar enough with ASDF internal API to write such a script on hobby time.

On a side note, this led me to a minor struggle, which is that I had to have the help.doc file in $PWD to be able to run the built program. I accidentally found the ECLDIR environment variable to specify a separate path to it, but I think this would need to be documented?


Best regards,

On 22.08.2017 00:27, Florian Margaine wrote:

I've been trying to build a real static binary for easy deployment.

So far, everything I've tried still links to libecl as a shared
library; is it possible to have a static library of it, so that my
static binary can bundle it?

I guess I kind of want to shy away from building ECL myself, it's kind
of a pain to require that for other developers working on this