| Summary: | sys-devel/gcc installs orphan /lib64/libgcc_s.so.1 on separate-/usr systems | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Herbert Wantesh <rauchwolke> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | CC: | rauchwolke |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 371735, 699798 | ||
| Bug Blocks: | |||
|
Description
Herbert Wantesh
2019-11-08 00:50:42 UTC
gcc-config tool (from sys-devel/gcc-config) creates /lib64/libgcc_s.so.1 as copy of /usr/lib/gcc/${CHOST}/${selected_gcc_version}/libgcc_s.so.1 ONLY WHEN /lib and /usr/lib/gcc/${CHOST}/${selected_gcc_version} are on separate mountpoints.
When these directories are in the same mountpoint, then there is no need to create /lib64/libgcc_s.so.1.
You probably have /usr on separate filesystem in some of your systems.
(In reply to Herbert Wantesh from comment #0) > After installing gentoo on 3 different PCs i found out, that > > /lib64/libgcc_s.so.1 isn't installed on all installations, although it gets > installed in > > "/usr/lib/gcc/x86_64-pc-linux-gnu/*/libgcc_s.so.1" on all systems > > It seems to get installed on some of my system in /lib64/libgcc_s.so.1 and > other systems seem to miss the file in /lib64/. > > If i try to find out which package provides /lib64/libgcc_s.so.1 (on systems > that have it installed) with > > # qfile /lib64/libgcc_s.so.1 > > I get no package name, although it gets replaced every time i install gcc. > > Is there a reason that some systems miss the file in /lib64 and the other > systems that include the file don't seem to track the package ownership of > the file? > > I also recompiled gcc on all systems but the behaviour stays the same > > All systems use an hardend amd64 image with > > COMMON_FLAGS="-march=native -O2 -pipe" > > > Reproducible: Always > > > > Expected Results: > /lib64/libgcc_s.so.1 on all system with a package that owns it I agree having an orphan file is unfortunate and we should own it somehow. File copying is handled here: https://gitweb.gentoo.org/proj/gcc-config.git/tree/gcc-config#n304 You get a file cony every time you switch gcc with gcc-config or rebuild gcc. Volatile nature of the file makes it hard to be owned by any package. gcc frequently links in libgcc_s.so.1 into most binaries/libraries. To make /bin/ binaries usable before /usr/ is mounted we need to place libgcc_s.so.1 into /lib as well. It is a hack. Normal location for libgcc_s.so.1 is something like /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libgcc_s.so.1 Thanks for your explanation, i was searching for hours and as the gcc ebuild is that eclass based it's hard to find out if the ebuild handles this. Is there a way to "expand" ebuilds to see what actually happens and gets executed when the package gets build? I think the /lib64/libgcc_s.so.1 should be at least marked as "special" as the package relatedness will be hard to achieve. (In reply to Herbert Wantesh from comment #3) > Thanks for your explanation, i was searching for hours and as the gcc ebuild > is that eclass based it's hard to find out if the ebuild handles this. > > Is there a way to "expand" ebuilds to see what actually happens and gets > executed when the package gets build? Not easily. The best view is the build.log of a package. > I think the /lib64/libgcc_s.so.1 should be at least marked as "special" as > the package relatedness will be hard to achieve. Yeah. I'll ask dev-portage@ if we can implement tracking of such mutable files to be able to track it back to gcc-config. Is this still happening? (In reply to Andreas K. Hüttel from comment #5) > Is this still happening? No response (In reply to Andreas K. Hüttel from comment #6) > (In reply to Andreas K. Hüttel from comment #5) > > Is this still happening? > > No response it still happens on a newly installed system, the file "/lib64/libgcc_s.so.1" is there, because the systems has a separate /usr partition but the file is still not owned by any package # ls -la /lib64/libgcc_s.so.1 -rw-r--r-- 1 root root 124784 Jun 27 00:04 /lib64/libgcc_s.so.1 # qfile /lib64/libgcc_s.so.1 # |
