Pierre Neidhardt 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...