Publish a libsbcl.a

[Faré]

This patch publishes a libsbcl.a that can be used by a modified CFFI (or by bazel.io) to build statically linked runtimes and standalone executables.

It's only useful if you build with --with-sb-dynamic-core

It tries to do something on Windows, but that's incomplete.

[Faré (fahree)]

Here's another pass, which removes the unused exported-symbols.lds file, and tries a bit harder on Windows (though it's still thoroughly untested).

Also, shouldn't we be making sb-dynamic-core the default no Linux (and everywhere?)

[Faré (fahree)]

Oh, and I tested this patch with a patched CFFI to produce static executable images using ASDF. See https://github.com/cffi/cffi/pull/73

[Gábor Melis (melisgl)]

Thank you. That's a really long awaited feature which should make
deploying executables much easier. I'll test it soonish and report
back.

On Tue, Sep 29, 2015 at 5:47 AM, Faré <email address hidden> wrote:
> Oh, and I tested this patch with a patched CFFI to produce static
> executable images using ASDF. See https://github.com/cffi/cffi/pull/73
>
> --
> You received this bug notification because you are subscribed to SBCL.
> https://bugs.launchpad.net/bugs/1500628
>
> Title:
> Publish a libsbcl.a
>
> Status in SBCL:
> New
>
> Bug description:
> This patch publishes a libsbcl.a that can be used by a modified CFFI
> (or by bazel.io) to build statically linked runtimes and standalone
> executables.
>
> It's only useful if you build with --with-sb-dynamic-core
>
> It tries to do something on Windows, but that's incomplete.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/sbcl/+bug/1500628/+subscriptions

[Faré (fahree)]

Between there being no portable way to link .a's together (unless you use the non-ubiquitous and hard to use libtool), and the -Wl,--whole-archive business (not available on native BSD linkers, e.g. on MacOS X), it seems more appropriate to use ld -r and have a sbcl.o rather than a libsbcl.a.

I will rewrite this patch accordingly, unless someone objects.

[Faré (fahree)]

cracauer committed my latest (and smallest) patch in f61d047c2d83ce6c7437a08223e69970ac561d2b

[Stas Boukarev (stassats)]

I had to revert the commit because it breaks the build on multiple configurations: OS X, Windows, 32-bit build on 64-bit linux. Just running ld seems to be not enough.

[Faré (fahree)]

Ouch.

For the linux x32, I suppose it's a matter of adding LDFLAGS = -m elf32-i386

For the other platforms... I don't know. It might be something similar. I have to investigate.

[Faré (fahree)]

OK, so one year later, I'm having another take at it:
https://github.com/fare/sbcl

Following the advice of stassats, I'm making it all dependent on a feature,
that I called SB-LINKABLE-RUNTIME, only available on platforms where I tested it.

I also produce a file sbcl.mk with Makefile variable definitions for CFFI or others to detect
what flags to use when building extensions to SBCL. When SB-LINKABLE-RUNTIME is enabled,
this will cause additional variables to appear in sbcl.mk, and corresponding files
to be copied to the SBCL_HOME to enable linking.

The feature is only currently available on macOS, Linux, Windows, x86-64 and x86. I tested on it on x86-64 on the three platforms.

[Faré (fahree)]

I also tried the above sb-linkable-runtime patch with Bazel on Linux x64, and it worked great. The Bazel build script for sbcl fails on macOS, though, so I can't test it.

[Faré (fahree)]

Today's procrastination was making sure that sb-linkable-runtime works with Bazel on macOS as well as on Linux (it also still works with ASDF and cffi-toolchain):
https://github.com/qitab/bazelisp

Please consider the attached patch, currently on top of:
https://github.com/fare/sbcl

[Faré (fahree)]

I rebased the patch and resolved the conflicts, and tested that it still works on Linux x64. I didn't re-try on macOS or Windows, but since there were no conflicts there I don't envision an issue.

Still at https://github.com/fare/sbcl

[Stas Boukarev (stassats)]

In 402a8fab62db036b2dd79ad4e91c41304d4c825d