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

[Török Edwin]

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 <address@hidden> skribis:
> 
>> On 2016-10-16 22:04, Ludovic Courtès wrote:
>>> Mark H Weaver <address@hidden> 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,