GNU bug report logs -
#33848
Store references in SBCL-compiled code are "invisible"
Previous Next
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Sun, 23 Dec 2018 14:21:02 UTC
Severity: important
Tags: fixed
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Pierre Neidhardt <mail <at> 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 (application/pgp-signature, inline)]
This bug report was last modified 4 years and 8 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.