GNU bug report logs - #53406
"grafts fail with different architecture inputs?"

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: John Kehayias <john.kehayias <at> protonmail.com>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: union-build incorrectly handles grafts
Date: Fri, 21 Jan 2022 06:48:38 +0000

[Message part 1 (text/plain, inline)]

Hello Guix,

Stumbled upon a mysterious problem today with grafts. Let me report what I see and how to reproduce it:

I'm attaching a minimal working example of the problem, namely using union-build creates the wrong symlink when a package has a propagated input that has a replacement. At least that seems to be the key ingredients. (Note the code originally came from another channel, so I left the header intact. The union-build looks the same as in e.g. python-pyqt+qscintilla though.)

It looks like a link is made to a wrong (i.e. previous) version library. It is pointing to the replacement package in the store, but trying to use the previous name.

If I run the attached file with guix build -f graft-test.scm and look at libexpat in the created package with, e.g.

ls -la $(guix build -f graft-test.scm)/lib/libexpat*

I get

lrwxrwxrwx 1 root root 71 Dec 31  1969 /gnu/store/a3ixqfx1cfjgbz5gb925fv7dwy2h55gs-fhs-union-0.0/lib/libexpat.la -> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.la*
lrwxrwxrwx 1 root root 71 Dec 31  1969 /gnu/store/a3ixqfx1cfjgbz5gb925fv7dwy2h55gs-fhs-union-0.0/lib/libexpat.so -> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so*
lrwxrwxrwx 1 root root 73 Dec 31  1969 /gnu/store/a3ixqfx1cfjgbz5gb925fv7dwy2h55gs-fhs-union-0.0/lib/libexpat.so.1 -> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1*
lrwxrwxrwx 1 root root 77 Dec 31  1969 /gnu/store/a3ixqfx1cfjgbz5gb925fv7dwy2h55gs-fhs-union-0.0/lib/libexpat.so.1.8.1 -> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1.8.1

Note that the last link is broken: looking at this expat library (2.4.3, the replacement) it has

-r-xr-xr-x 1 root root  961 Dec 31  1969 /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.la*
lrwxrwxrwx 1 root root   17 Dec 31  1969 /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so -> libexpat.so.1.8.3*
lrwxrwxrwx 1 root root   17 Dec 31  1969 /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1 -> libexpat.so.1.8.3*
-r-xr-xr-x 2 root root 191K Dec 31  1969 /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1.8.3*

This is why the last link from the union-build package is broken, it tries to point to libexpat.so.1.8.1 (the previous version, but in the newer version's directory).

There are no error or warnings that I saw in building the package or in a profile (e.g. guix shell). I put in an output in the builder to see what directories were passed to the union-build, giving me

directories: (/gnu/store/d0xskl9xjb0z6miaf87xszi8iq6h8sqs-apr-util-1.6.1 /gnu/store/iwcw80p8lkqsqbvchjvypvl06qlbjc3d-expat-2.4.1)

So the original expat propagated-input store directory is passed to the builder (as expected), but in the end it does use the replacement version. Just with a version number gone wrong in a library link.

I came across this actually when combining both x86_64 and i686 into a single profile. There it would error on a conflict between file and directory, but in the lib/cmake of expat, again something with different version numbers appearing but between x86_64 and i686. I don't have an example of that handy right now, but it sent me in the direction of seeing why expat was coming up, when I came across this (I'm guessing leading to the problem I saw).

In case it is relevant, I did notice other packages have had explicit replacements used in propagated inputs previously, like in https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c5df560fd3762c0dbe99562f52223c73d445e597 expat is propagated by fontconfig and apr-util, possibly other places? A bit tricky to search with the expat license and all.

This was on commit: e415a73d2c11e43f4db3b797ed73ab6ebcc336e0 My original problem (conflict in x86_64 and i686 union) happened after the expat replacement commit, 2045852b096131a714409aa0cc4fe17938f60b15 which was my first clue.

I hope that is helpful in reproducing and finding out what is happening. Something to do with union-build I guess, but it is very late here right now so I hope this all made sense. Happy to help investigate and debug.

John

[graft-test.scm (text/x-scheme, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.