Kirill A. Korinsky <kir...@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
