Bug 555816 – bootstrap-prefix.sh stage2: Emerged xz fails to load liblzma.so.5

• Product: Gentoo/Alt
• Status: RESOLVED OBSOLETE

[Description gilad.arnold 2015-07-24 18:59:52 UTC]

As part of the basic dependencies built in stage2, app-arch/xz-utils is emerged. This seems to work fine, except that emerging sys-devel/m4 right afterwards fails to unpack the source package (m4-1.4.17.tar.xz):

xz: /lib/x86_64-linux-gnu/liblzma.so.5: version 'XZ_5.2' not found (required by xz)

This seems to be the host liblzma.so.5.0.0 complaining. For some reason, the program $EPREFIX/tmp/usr/bin/xz, which requires liblzma.so.5, links against the host library instead of the one in $EPREFIX/tmp/lib/liblzma.so.5 (symlink to the liblzma.so.5.2.1 that was built with xz-utils).

I worked around the issue by temporarily adding $EPREFIX/tmp/usr/lib/liblzma.so.5 -> ../../lib/liblzma.so.5.

This might be due to this being a Ubuntu 14 host, but may also be a problem with RPATH/RUNPATH when building xz-utils?

[Comment 1 gilad.arnold 2015-07-28 23:19:45 UTC]

Prepending this to do_emerge_pkgs call (in emerge_pkgs() in bootstrap_stage2()) allows it to run smoothly:

 LD_LIBRARY_PATH="${ROOT}/tmp/usr/lib:${ROOT}/tmp/lib"

Is this an acceptable fix? If so, I can submit a patch.

[Comment 2 gilad.arnold 2015-07-29 19:16:10 UTC]

Same LD_LIBRARY_PATH prepending needed for the stage3 emerge_pkgs().

That said, while this happened to work on my setup, I don't think it's a good solution, as it might cause innocent host binaries to load stage2 Prefix libraries... bad idea.

Looking more closely, the problem is that the DT_RPATH value found in the stage2 xz binary (EPREFIX/tmp/usr/lib) is inconsistent with the actual location of liblzma.so.5 (EPREFIX/tmp/lib). This may have to do with issue 4411 and how it affects installation locations for libraries. Strangely, though, the stage3 xz binary does not have this problem: it uses DT_RUNPATH (instead of RPATH) that properly covers all Prefix locations (in fact, with some redundancy):

 EPREFIX/usr/lib
 EPREFIX/usr/x86_64-pc-linux-gnu/lib/gcc
 EPREFIX/usr/x86_64-pc-linux-gnu/lib
 EPREFIX/usr/lib
 EPREFIX/lib
 EPREFIX/tmp/usr/x86_64-pc-linux-gnu/lib/gcc
 EPREFIX/tmp/usr/x86_64-pc-linux-gnu/lib
 EPREFIX/tmp/lib
 EPREFIX/tmp/usr/lib

Both the stage2 and stage3 xz-utils were built with -rpath the corresponded to their install prefix (.../usr/lib) so I don't really get where the difference is coming from (different gcc/binutils?). Regardless, the fact that the stage2 xz doesn't load the correct library is still a problem that (IMO) needs to be fixed.

[Comment 3 Fabian Groffen 2021-01-06 12:48:51 UTC]

this changed significantly since this bugreport, and needs revisiting