Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 699588 - sys-devel/gcc installs orphan /lib64/libgcc_s.so.1 on separate-/usr systems
Summary: sys-devel/gcc installs orphan /lib64/libgcc_s.so.1 on separate-/usr systems
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on: 371735 699798
Blocks:
  Show dependency tree
 
Reported: 2019-11-08 00:50 UTC by Herbert Wantesh
Modified: 2019-12-16 19:22 UTC (History)
0 users

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 Herbert Wantesh 2019-11-08 00:50:42 UTC
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
Comment 1 Arfrever Frehtes Taifersar Arahesis 2019-11-08 02:49:53 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.
Comment 2 Sergei Trofimovich gentoo-dev 2019-11-08 07:44:01 UTC
(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
Comment 3 Herbert Wantesh 2019-11-08 23:15:52 UTC
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.
Comment 4 Sergei Trofimovich gentoo-dev 2019-11-08 23:42:03 UTC
(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.