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?
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.
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.
this changed significantly since this bugreport, and needs revisiting
