sys-apps/portage is missing a dependency on libgcc_s.so.1. similarly to bug 740744, this means that bootstrapping new system e.g. with: emerge --root /new/gentoo/system portage fails, since running portage from the resulting tree causes portage exit with an error: libgcc_s.so.1 must be installed for pthread_cancel to work Emerging sys-devel/gcc into the new system fixes this problem.
Wouldn't this rather be a dependency of the python interpreter?
In case it helps for your use case, I would typically use these options for the type of command that you're using: --usepkgonly --ignore-soname-deps=n --quickpkg-direct=y (if I don't have binary packages yet) With the --usepkgonly and --ignore-soname-deps=n options, the libgcc_s.so.1 should be pulled in automatically as an soname dependency.
same problem here, libgcc_s.so.1 is required when python is using multi-threading. I also tried (minimal use: USE="-* python_targets_python3_9"): emerge --root /new/gentoo/system flask It fails with the same error, copying libgcc_s.so.1 in /new/gentoo/system/usr/lib64/ fixes the issue. I played with --ignore-soname-deps=n (I did not know this, thanks Zac), it definitley helps at finding missing dependencies when messing around with them. But in this particular case, it does not pull sys-devel/gcc. I realized /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgcc_s.so.1 is not executable, this may be why soname-deps doesn't detect it? is there a reason not to be executable? I'm using emerge --root to namespace/sandbox certain applications and to build an initrd, would there be a "portage" way to pull in libgcc_s.so.1 without the full gcc and its dependencies (gmp, mpfr, mpc)?
(In reply to Michel Ganguin from comment #3) > same problem here, libgcc_s.so.1 is required when python is using > multi-threading. I also tried (minimal use: USE="-* > python_targets_python3_9"): > > emerge --root /new/gentoo/system flask > > It fails with the same error, copying libgcc_s.so.1 in > /new/gentoo/system/usr/lib64/ fixes the issue. > > I played with --ignore-soname-deps=n (I did not know this, thanks Zac), it > definitley helps at finding missing dependencies when messing around with > them. But in this particular case, it does not pull sys-devel/gcc. I > realized /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/libgcc_s.so.1 is not > executable, this may be why soname-deps doesn't detect it? is there a reason > not to be executable? emerge does not check the executable bit. We should check the PROVIDES metadata for the binary package. For example, se how mine looks: > $ grep '^PROVIDES: .*libgcc_s' /var/cache/binpkgs/Packages > PROVIDES: x86_32: libasan.so.5 libatomic.so.1 libgcc_s.so.1 libgdruntime.so.76 libgfortran.so.5 libgo.so.14 libgomp.so.1 libgphobos.so.76 libitm.so.1 libquadmath.so.0 libstdc++.so.6 libubsan.so.1 libvtv.so.0 x86_64: libasan.so.5 libatomic.so.1 libcc1.so.0 libcc1plugin.so.0 libcp1plugin.so.0 libgcc_s.so.1 libgdruntime.so.76 libgfortran.so.5 libgo.so.14 libgomp.so.1 libgphobos.so.76 libitm.so.1 liblsan.so.0 liblto_plugin.so.0 libquadmath.so.0 libstdc++.so.6 libtsan.so.0 libubsan.so.1 libvtv.so.0 > PROVIDES: x86_32: libasan.so.5 libatomic.so.1 libgcc_s.so.1 libgdruntime.so.76 libgfortran.so.5 libgo.so.14 libgomp.so.1 libgphobos.so.76 libitm.so.1 libquadmath.so.0 libstdc++.so.6 libubsan.so.1 libvtv.so.0 x86_64: libasan.so.5 libatomic.so.1 libcc1.so.0 libcc1plugin.so.0 libcp1plugin.so.0 libgcc_s.so.1 libgdruntime.so.76 libgfortran.so.5 libgo.so.14 libgomp.so.1 libgphobos.so.76 libitm.so.1 liblsan.so.0 liblto_plugin.so.0 libquadmath.so.0 libstdc++.so.6 libtsan.so.0 libubsan.so.1 libvtv.so.0 > $ grep libgcc_s /var/db/pkg/*/*/PROVIDES > /var/db/pkg/sys-devel/gcc-9.2.0-r2/PROVIDES:x86_32: libasan.so.5 libatomic.so.1 libgcc_s.so.1 libgdruntime.so.76 libgfortran.so.5 libgo.so.14 libgomp.so.1 libgphobos.so.76 libitm.so.1 libquadmath.so.0 libstdc++.so.6 libubsan.so.1 libvtv.so.0 x86_64: libasan.so.5 libatomic.so.1 libcc1.so.0 libcc1plugin.so.0 libcp1plugin.so.0 libgcc_s.so.1 libgdruntime.so.76 libgfortran.so.5 libgo.so.14 libgomp.so.1 libgphobos.so.76 libitm.so.1 liblsan.so.0 liblto_plugin.so.0 libquadmath.so.0 libstdc++.so.6 libtsan.so.0 libubsan.so.1 libvtv.so.0 > /var/db/pkg/sys-devel/gcc-9.3.0-r1/PROVIDES:x86_32: libasan.so.5 libatomic.so.1 libgcc_s.so.1 libgdruntime.so.76 libgfortran.so.5 libgo.so.14 libgomp.so.1 libgphobos.so.76 libitm.so.1 libquadmath.so.0 libstdc++.so.6 libubsan.so.1 libvtv.so.0 x86_64: libasan.so.5 libatomic.so.1 libcc1.so.0 libcc1plugin.so.0 libcp1plugin.so.0 libgcc_s.so.1 libgdruntime.so.76 libgfortran.so.5 libgo.so.14 libgomp.so.1 libgphobos.so.76 libitm.so.1 liblsan.so.0 liblto_plugin.so.0 libquadmath.so.0 libstdc++.so.6 libtsan.so.0 libubsan.so.1 libvtv.so.0 > I'm using emerge --root to namespace/sandbox certain applications and to > build an initrd, would there be a "portage" way to pull in libgcc_s.so.1 > without the full gcc and its dependencies (gmp, mpfr, mpc)? Currently, something like INSTALL_MASK is the only way. Ultimately, I want to solve this kind of issue as described in bug 772380, using an EAPI extension to divide content into parts that can be selected with USE flags.