Control: severity -1 serious On Tue, May 04, 2021 at 01:03:16PM +0200, Aurelien Jarno wrote: > When dpkg-cross converts a native package into a cross package, it moves > around libraries updating symlinks. It most notably moves the dynamic > loader, but doesn't update the path in the content of linker scripts > like /usr/lib/$(MULTIARCH)/libc.so. > > For example on armhf the dynamic loader is move from: > /lib/arm-linux-gnueabihf/ld-2.31.so > to > /usr/arm-linux-gnueabihf/lib/ld-2.31.so > > However this path is not updated in libc.so script, which is changed > from: > GROUP ( /lib/arm-linux-gnueabihf/libc.so.6 > /usr/lib/arm-linux-gnueabihf/libc_nonshared.a AS_NEEDED ( > /lib/ld-linux-armhf.so.3 ) ) > to > GROUP ( /usr/arm-linux-gnueabihf/lib/libc.so.6 > /usr/arm-linux-gnueabihf/lib/libc_nonshared.a AS_NEEDED ( > /lib/ld-linux-armhf.so.3 ) ) > > The path in AS_NEEDED should also be updated.
The main purpose of dpkg-cross is converting library packages and basically the only library it really needs to work on to be useful is glibc. It now fails at this task, which essentially makes dpkg-cross unusable. As such, I'm upgrading the severity to serious. This really needs to be fixed in bullseye. I've looked into dpkg-cross and the fix_ldscripts sub in particular. I have to admit that I'm quite puzzled about how it behaves differently on multiarch vs non-multiarch packages as well as how it identifies them. I'll explain my understanding and propose a solution below. Review and tesing welcome. dpkg-cross identifies packages as "multiarch" if they carry a Multi-Arch stanza or put any file on a multiarchy path (such as /usr/include/<triplet> or /usr/lib/<triplet>). Once identified as "multiarch" dpkg-cross and the ldscript fixer in particular work differently. It seems as if dpkg-cross does not consider that packages may be "partially multiarch" (i.e. using multiarch and non-multiarch paths). In particular, glibc is partially multiarch and dpkg-cross fails to handle this. Please tell if there is a mistake in this logic somehow. The fix_ldscript sub does not fix up non-multiarch paths inside ldscripts if a package is identified as being "multiarch". In the case of libc6-dev, this results in the dynamic loader path not being fixed. In particular, it only ever fixes non-multiarch multilib paths, but never fixes plain non-multiarch paths (such as /lib without a triplet), which is precisely the case relevant to glibc. It does however move the library paths inside the package. I have no explanation for this inconsistency. As a minimally invasive solution (until we understand why multiarch is handled differently here), I propose handling the dynamic loader specially and fixing it up regardless of whether the package is multiarch. I'm attaching a patch to this end. It only fixes /lib, /lib32, /lib64 and /libx32 as no other multilib ever contained a dynamic loader. The difficult part here is finding a solution that does not break anything. I've practically observed the issue for various gcc-10 and gcc-11 based bootstrap sequences and they all fail finding the unconverted loader while linking libc.so into libgcc during gcc stage3. For gcc-10/arm64, I've locally verified that the patch fixes the issue. I'm running various combinations on jenkins with it now to see how it fixes other combinations. My preference here is not reverthing the glibc/2.31-12 change that introduced this regression and rather fix up dpkg-cross. Replies to this mail that point out errors or indicate their absence are welcome. Helmut
