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
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 #