Hi Mark, Mark H Weaver <m...@netris.org> skribis:
> I think that my last hypothesis was on the right track, but not quite > right: > > * Instead of 'libcairo' being loaded twice, I now suspect that > "libguile-cairo.so" is being loaded twice. > > * Instead of the original and replacement libraries being loaded, I now > suspect that two different variants of the replacement "guile-cairo" > are being loaded. > > * Instead of libcairo type tags being duplicated, I now suspect that > duplicated smob tags are being allocated. > > However, *if* deduplication is enabled, two redundant replacements > created by grafting _should_ occupy the same inodes, assuming that the > replacement mappings are the same (modulo ordering), and assuming that > /gnu/store/.links doesn't hit a directory size limit (which can happen > on ext3/4, leading to missed deduplication opportunities). Woow, thanks for the investigation! You wouldn’t think that deduplication can have an effect on this kind of bug. > I've known about these redundant replacements in Guix for many years, > but was not aware of any significant practical problems arising from > them until now. Do you know why the two guile-cairo grafts differ in this case? I’m aware of one case that can lead to that: the grafting code can create grafts for just one output of the original derivation, or for all of them (commit 482fda2729c3e76999892cb8f9a0391a7bd37119). Maybe that’s what’s happening here? Thank you! Ludo’.
