bug#33848: Store references in SBCL-compiled code are "invisible"

[Guillaume Le Vaillant]

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Hi Guillaume!
>
>> A store reference to a C library in a standalone Lisp binary can come
>> either from the current package or from some dependencies
>> (cl+ssl, cl-cffi-gtk, etc.). So we would need to scan the source
>> code of all the Lisp dependencies recursively to get the full list of
>> store refrences.
>
> I don't think there is need to scan recursively: if package A depends on
> B which depends on C, then A can lists the dependency on B in a file,
> and B can do the same for C.  This way the relationship between A and C
> is properly stored.
>
> Am I missing something?

Oh, you say this file would be created for every Lisp package. I thought
it would only be for the standalone binary case, because the "regular"
asdf-build-system/sbcl used for Lisp libraries ships the sources and its
make-asdf-configuration phase creates links to the required Lisp
dependencies in '/gnu/store/...', so there should not be missing
references.


>> And as Mark wrote below, with the current grafting code, this list of
>> store references will not solve grafting for paths that are in UTF-32 or
>> both in ASCII and UTF-32 in the binary file.
>
> Indeed, and that's the core of the issue here I believe, since grafting
> is what breaks Nyxt in practice.
>
> Cheers!

I just wondered: does the grafting code take '.fasl' files into
consideration?
If yes, I guess a Lisp library could also end up in a strange
half-grafted state if the grafting code modifies ASCII references and
not UTF-32 ones...

signature.asc
Description: PGP signature