View Issue Details

IDProjectCategoryView StatusLast Update
0006535Rocky-Linux-8basesystempublic2024-11-27 01:49
ReporterJames Lowden Assigned ToLouis Abel  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionsuspended 
Platformx86_64OSRocky LinuxOS Version8.9
Summary0006535: libstdc++ package does not install top-level link
Description`yum info libstdc++-8.5.0-20.el8.x86_64` says it's part of the baseos repo, and that it is the "GNU Standard C++ Library". But it does not include `libstdc++.so`:

$ rpm -q --list libstdc++-8.5.0-20.el8.x86_64 | grep \\.so
/usr/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6.0.25
...

The consequence is that ld(1) fails to find the library when it looks in the "usual" place, `/lib64`. At least, that's one of the places the gcc configure script expects it to be.

When the C++ _compiler_ is installed, it adds its runtime library, with a top-level symlink, in an obscure location specific to its version:

$ rpm -q --list $(rpm -q --whatprovides $(which g++)) | grep so$
/usr/lib/gcc/x86_64-redhat-linux/8/32/libstdc++.so
/usr/lib/gcc/x86_64-redhat-linux/8/libstdc++.so

But that library is inaccessible to anyone not using g++.

I do not understand why libstdc++-8.5.0-20.el8.x86_64 does not install /lib64/libstdc++.so, or how the user is supposed to install the C++ standard library such that the linker will find it (with or without -L).

IMO btw the base system should put `/Lib64` in /etc/ld.so.conf. The linker is looking by default in /usr/lib, which evidently is not where 64-bit libraries are kept, and *not* by default in /lib64, which is where they are. Because the linker is not configured to use a reasonable default, all users of the linker are forced to add a search path.
TagsNo tags attached.

Activities

Louis Abel

Louis Abel

2024-05-08 03:55

administrator   ~0006966

Thank you for the report.

>`yum info libstdc++-8.5.0-20.el8.x86_64` says it's part of the baseos repo, and that it is the "GNU Standard C++ Library". But it does not include `libstdc++.so`
>When the C++ _compiler_ is installed, it adds its runtime library, with a top-level symlink, in an obscure location specific to its version

This is correct. libstdc++.so (as you pointed out later) is a symlink. This is by design in Red Hat based distributions. The actual library will be libstdc++.so.6.0.25 where libstdc++.so.6 is also a symlink.

I would take a look at the spec file if you are interested to see how it is laid out. https://git.rockylinux.org/staging/rpms/gcc/-/blob/14def39ce9d154610f7603c1126a6a0f9241645e/SPECS/gcc.spec

What you will find is that this is by design in Red Hat based distributions. For our case, libstdc++.so.6 will be a symlink to the actual library, which is libstdc++.so.6.0.25.

>But that library is inaccessible to anyone not using g++

It's accessible. It's available in /lib64 as a dynamic library.

<mock-chroot> sh-4.4# ldconfig -p | grep libstdc
        libstdc++.so.6 (libc6,x86-64) => /lib64/libstdc++.so.6

>IMO btw the base system should put `/Lib64` in /etc/ld.so.conf. The linker is looking by default in /usr/lib, which evidently is not where 64-bit libraries are kept, and *not* by default in /lib64, which is where they are. Because the linker is not configured to use a reasonable default, all users of the linker are forced to add a search path

Adding /lib64 as an explicit path to /etc/ld.so.conf doesn't quite make sense as it's already in the default search path. In fact, /lib64 ultimately shows up first if you run ld --verbose.

<mock-chroot> sh-4.4# ld --verbose | grep SEARCH_DIR
SEARCH_DIR("=/usr/x86_64-redhat-linux/lib64"); SEARCH_DIR("=/usr/lib64"); SEARCH_DIR("=/usr/local/lib64"); SEARCH_DIR("=/lib64"); SEARCH_DIR("=/usr/x86_64-redhat-linux/lib"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib");

--

We need more information and context as it pertains to your build environment. The locations set out by glibc, gcc and their accompanying packages (libstdc++ and gcc-c++ in this case) are standard on Red Hat based distributions. Rocky Linux, being a RHEL derivative is one of those.

Setting to needinfo.

Issue History

Date Modified Username Field Change
2024-05-07 16:11 James Lowden New Issue
2024-05-08 03:55 Louis Abel Assigned To => Louis Abel
2024-05-08 03:55 Louis Abel Status new => needinfo
2024-05-08 03:55 Louis Abel Note Added: 0006966
2024-11-27 01:49 Louis Abel Status needinfo => closed
2024-11-27 01:49 Louis Abel Resolution open => suspended