Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 740746 - sys-apps/portage-3.0.4-r1 missing dependency on libgcc_s.so.1
Summary: sys-apps/portage-3.0.4-r1 missing dependency on libgcc_s.so.1
Status: UNCONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-06 21:27 UTC by Petr Cerny [:hrosik]
Modified: 2022-04-01 09:31 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Cerny [:hrosik] 2020-09-06 21:27:11 UTC
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.
Comment 1 Zac Medico gentoo-dev 2020-09-06 21:48:39 UTC
Wouldn't this rather be a dependency of the python interpreter?
Comment 2 Zac Medico gentoo-dev 2020-09-06 22:57:45 UTC
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.
Comment 3 Michel Ganguin 2021-03-28 13:53:14 UTC
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)?
Comment 4 Zac Medico gentoo-dev 2021-03-28 14:58:41 UTC
(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.