I am not sure if this actually a case of a missing dependency, but I've encountered a problem with libarchive tar after updating dev-libs/icu, causing subsequent builds to fail, e.g.: * Messages for package dev-libs/boost-1.82.0-r1: * ERROR: dev-libs/boost-1.82.0-r1::gentoo failed (unpack phase): * unpack: failure unpacking boost_1_82_0.tar.bz2 * * Call stack: * ebuild.sh, line 136: Called src_unpack * environment, line 3255: Called default * phase-functions.sh, line 872: Called default_src_unpack * phase-functions.sh, line 899: Called __eapi0_src_unpack * phase-helpers.sh, line 807: Called unpack 'boost_1_82_0.tar.bz2' * phase-helpers.sh, line 439: Called __unpack_tar 'bzip2 -d' * phase-helpers.sh, line 372: Called __assert_sigpipe_ok 'unpack: failure unpacking boost_1_82_0.tar.bz2' * isolated-functions.sh, line 41: Called die * The specific snippet of code: * [[ ${x} -ne 0 && ${x} -ne ${PORTAGE_SIGPIPE_STATUS:-141} ]] && die "$@" * * If you need support, post the output of `emerge --info '=dev-libs/boost-1.82.0-r1::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-libs/boost-1.82.0-r1::gentoo'`. * The complete build log is located at '/var/tmp/portage/dev-libs/boost-1.82.0-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/boost-1.82.0-r1/temp/environment'. * Working directory: '/var/tmp/portage/dev-libs/boost-1.82.0-r1/work' * S: '/var/tmp/portage/dev-libs/boost-1.82.0-r1/work/boost_1_82_0' Looking at build.log: >>> Unpacking source... >>> Unpacking boost_1_82_0.tar.bz2 to /var/tmp/portage/dev-libs/boost-1.82.0-r1/work tar: error while loading shared libraries: libicuuc.so.72: cannot open shared object file: No such file or directory Reproducible: Always Steps to Reproduce: 1. Grab a system with an old version of dev-libs/icu (e.g. 72) 2. Install app-arch/libarchive 3. Update dev-libs/icu to 73.1 4. Try to run any libarchive tool Actual Results: tar: error while loading shared libraries: libicuuc.so.72: cannot open shared object file: No such file or directory Expected Results: Whatever tool is run (in my case tar) should work as always. Output from ldd shows that app-arch/libarchive is linked against libicuuc.so. Before rebuilding: # ldd /usr/lib64/libarchive.so linux-vdso.so.1 (0x00007ffee2bf1000) libcrypto.so.3 => /usr/lib64/libcrypto.so.3 (0x00007ff2af017000) libacl.so.1 => /lib64/libacl.so.1 (0x00007ff2af00c000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007ff2aefde000) libzstd.so.1 => /lib64/libzstd.so.1 (0x00007ff2aef28000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007ff2aef15000) libz.so.1 => /lib64/libz.so.1 (0x00007ff2aeefb000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007ff2aed92000) libc.so.6 => /lib64/libc.so.6 (0x00007ff2aebbf000) libicuuc.so.72 => not found libm.so.6 => /lib64/libm.so.6 (0x00007ff2aeae4000) /lib64/ld-linux-x86-64.so.2 (0x00007ff2af53b000) After rebuilding: (chroot) nex-gentoo-bin / # ldd /usr/lib64/libarchive.so linux-vdso.so.1 (0x00007ffce3314000) libcrypto.so.3 => /usr/lib64/libcrypto.so.3 (0x00007f9ffac0e000) libacl.so.1 => /lib64/libacl.so.1 (0x00007f9ffac03000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f9ffabd5000) libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f9ffab1f000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f9ffab0c000) libz.so.1 => /lib64/libz.so.1 (0x00007f9ffaaf2000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007f9ffa989000) libc.so.6 => /lib64/libc.so.6 (0x00007f9ffa7b6000) libicuuc.so.73 => /usr/lib64/libicuuc.so.73 (0x00007f9ffa5b7000) libm.so.6 => /lib64/libm.so.6 (0x00007f9ffa4dc000) /lib64/ld-linux-x86-64.so.2 (0x00007f9ffb132000) libicudata.so.73 => /usr/lib64/libicudata.so.73 (0x00007f9ff8653000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/12/libstdc++.so.6 (0x00007f9ff8431000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/12/libgcc_s.so.1 (0x00007f9ff8412000)
Created attachment 865281 [details] emerge --info Note that while the gentoo repo shows a different sync-uri, the last sync was made against an official Gentoo mirror a few hours ago.
You appear to have FEATURES="-preserve-libs" (preserve-libs is the default), so if your tar uses libarchive and libarchive is linked with ICU, it's broken. Let's use preserve-libs.eclass (which is for *-preserve-libs* users, not preserve-libs users) in ICU given ICU is really a critical system library anyway, not just because of libarchive.
