Kirill A. Korinsky <kirill@korins.ky> writes:

> On Thu, 25 Apr 2024 14:11:32 +0200,
> Sebastien Marie wrote:
>> 
>> The static-library is simple to add (with --with-sb-linkable-runtime
>> support).
>>
>
> Which requires at least this patch

yes. I already have sent to upstream the full support for
--with-sb-linkable-runtime.

> diff --git src/cold/shared.lisp src/cold/shared.lisp
> index 773d36115..a7c55ea6c 100644
> --- src/cold/shared.lisp
> +++ src/cold/shared.lisp
> @@ -392,7 +392,7 @@
>           ("(and cons-profiling (not sb-thread))" ":CONS-PROFILING requires :SB-THREAD")
>           ("(and sb-linkable-runtime (not (or arm arm64 x86 x86-64 ppc ppc64)))"
>            ":SB-LINKABLE-RUNTIME not supported on selected architecture")
> -         ("(and sb-linkable-runtime (not (or darwin freebsd linux win32)))"
> +         ("(and sb-linkable-runtime (not (or darwin freebsd openbsd linux win32)))"
>            ":SB-LINKABLE-RUNTIME not supported on selected operating system")
>           ("(and sb-eval sb-fasteval)"
>            ;; It sorta kinda works to have both, but there should be no need,
>
>
> Anyway, I haven't tested it.
>
> But this discussion put in my head another idea: build libsbcl.so indeed,
> but using it also inside sbcl binary.
>
> This way allows to solve an issue with rebuild of ports which saves lisp
> image as binary.
>
> But this approach requires some work inside sbcl build system.

I thought of that too, but I am still unsure it will solves the issue
(at least directly). Yes, the stumpwm package will be update
automatically, but because of WANTLIB change.

I am unsure a binary linked with old libsbcl.so will be runable with a
newer libsbcl.so. It might be something to try...

Thanks
-- 
Sebastien Marie