bug#24703: Store references in 8-byte chunks in compiled code

["Török Edwin" <edwin+ml-guix@etorok.net>]

On 2016-10-17 12:42, Mark H Weaver wrote:
> 
> Here's how to recover, for now:
> 
>   guix build --no-grafts -e '(@@ (gnu packages fontutils) fontconfig/fixed)'

Thanks!

On 2016-10-17 15:09, Ludovic Courtès wrote:
> Török Edwin <edwin+ml-guix@etorok.net> skribis:
> 
>> On 2016-10-16 22:04, Ludovic Courtès wrote:
>>> Mark H Weaver <mhw@netris.org> skribis:
>>>
>>>> When grafting, how will we achieve confidence that we've found the
>>>> correct occurrence of the last character?  I think we will have to give
>>>> up our recently added feature of being able to change the version number
>>>> of grafts.
>>>
>>> Wait, don’t jump to the conclusions.  :-)
>>
>> I've just encountered the same problem with fontconfig (after installing GuixSD, running guix pull and guix system reconfigure, --no-grafts was required).
>> Would it be possible for the grafts to keep a symlink (somehow registered to be part of the grafted fontconfig so that guix gc doesn't remove it) instead of patching the binaries?
>> /gnu/store/<old-hash>-fontconfig-2.11.94 -> /gnu/store/<grafted-hash>-fontconfig-2.11.94
> 
> We could use a self symlink

I'm new here [*] and I'd like to understand what solutions would be possible, could you please explain how the self symlink would work?

I was thinking about bind mounts (the list of needed bind mounts would be maintained as a derivation, and initialized from initrd maybe?):
/gnu/store/<new-hash>-fontconfig-2.11.94 on /gnu/store/<old-hash>-fontconfig-2.11.94

or equivalently another layer of symlinks (where /gnu/store is the mutable symlink graft location, and /gnu/immutablestore is the real destination):
/gnu/store/<old-hash>-fontconfig-2.11.94 -> /gnu/immutablestore/<new-hash>-fontconfig-2.11.94
/gnu/store/<new-hash>-fontconfig-2.11.94 -> /gnu/immutablestore/<new-hash>-fontconfig-2.11.94

However bit worried of what happens to running applications: they might end up loading libs/data from both old-hash and new-hash, but
it wouldn't be worse than what happens on a traditional distribution when you upgrade say libc, you need to restart things using it eventually.

> or we could use something like
> <http://git.savannah.gnu.org/cgit/guix.git/commit/?id=9d50da70608de32d9db0c29859caec6f2cddb95f>.

IMHO binary rewriting should be a last resort, it is too low-level and depends on the compiler/version to get it right.

[*] I've briefly tried NixOS and GuixSD in the past, but I'm using Debian and Gentoo as my main OS.
IIUC what the current grafting process does is that it reads all files of packages that depend on X from the store,
and writes them under a new hash with all references to hash of X replaced by hash of X-fixed, a bit like patchELF
except strings remain same size.

Best regards,