Statically linking C code into ECL

[Faré]

On Mon, Dec 26, 2016 at 5:02 AM, Daniel Kochmański <daniel at turtleware.eu> wrote:
> What do you mean by 'linking C file'? If you want to compile independent
> C file with ECL, then you are out of luck, because there is no official
> support for that in ECL's builder. It may work by passing file as one of
> lisp-files to builder, because ECL uses C files *internally*, but it's
> far from encouraged or official.
>
Is there an official or encouraged way?

I'm trying to achieve for ECL what I now have for SBCL and CLISP, a
single-executable output with both Lisp and C code linked together. If
I link things myself, I don't have the magic ecl initialization code;
if I don't, I can't convince ECL to pass the correct flags.

> As a side note, I see you use there c::builder, which is also
> internal. Exported interfaces are build-fasl, build-program,
> build-static-library and build-shared-library (it doesn't make a
> difference right now, but in the future builder interface may change,
> while the mentioned functions wont).
>
I was "just" reusing the old pattern from asdf-ecl, and hadn't noticed
the new interface. I will update cffi-toolchain and uiop/image.

> builder (and all interfaces built on top of it) support ld-flags key
> argument. Additionally if you want to influence how ECL compiles files
> dynamically you may shadow *user-cc-flags* and *user-ld-flags*.
>
This won't work. *user-cc-flags* isn't used by build-program, AFAICT,
and user-ld-flags is only used at the end of the linking command,
which is too late for a --whole-archive (and a --no-whole-archive is
actually needed before the -ldl -lm etc. calls, whereas on Darwin, the
-force_load is needed in front of each individual .a).

I suppose I could force linking of .o's and never .a's. Sigh.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Mathematics is as little a science as grammar is a language. — Ernst Mayr