Bug 32415 - libgcc_s not found in library search path with --enable-version-specific-runtime-libs
Summary: libgcc_s not found in library search path with --enable-version-specific-runt...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: 4.1.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 35248 35277 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-06-20 11:52 UTC by Lionel Barnett
Modified: 2023-01-19 15:22 UTC (History)
19 users (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Known to work:
Known to fail: 4.2.3, 4.3.0, 4.4.0
Last reconfirmed: 2023-01-19 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Barnett 2007-06-20 11:52:22 UTC 
Minimal program in test.c:

int main() {}

Compile:

# /var/scratch/lionelb/usr/gcc-4.1.2/bin/gcc -v test.c
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /var/scratch/lionelb/usr/src/gcc-4.1.2/configure --prefix=/var/scratch/lionelb/usr/gcc-4.1.2 --enable-languages=c,c++,fortran --enable-version-specific-runtime-libs --with-build-time-tools=/var/scratch/lionelb/usr/binutils-2.17/bin --with-as=/var/scratch/lionelb/usr/binutils-2.17/bin/as --with-ld=/var/scratch/lionelb/usr/binutils-2.17/bin/ld --enable-__cxa_atexit
Thread model: posix
gcc version 4.1.2
 /var/scratch/lionelb/usr/gcc-4.1.2/libexec/gcc/x86_64-unknown-linux-gnu/4.1.2/cc1 -quiet -v test.c -quiet -dumpbase test.c -mtune=k8 -auxbase test -version -o /tmp/cc92Pr4G.s
ignoring nonexistent directory "/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /var/scratch/lionelb/usr/gcc-4.1.2/include
 /var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/include
 /usr/include
End of search list.
GNU C version 4.1.2 (x86_64-unknown-linux-gnu)
	compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-8).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2f59716e3dacf2fffffc2f167478c592
 /var/scratch/lionelb/usr/binutils-2.17/bin/as -V -Qy -o /tmp/ccgIgKwi.o /tmp/cc92Pr4G.s
GNU assembler version 2.17 (x86_64-unknown-linux-gnu) using BFD version 2.17
 /var/scratch/lionelb/usr/gcc-4.1.2/libexec/gcc/x86_64-unknown-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/crtbegin.o -L/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2 -L/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/ccgIgKwi.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/crtend.o /usr/lib/../lib64/crtn.o
/var/scratch/lionelb/usr/binutils-2.17/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status

Now:

# find /var/scratch/lionelb/usr/gcc-4.1.2 -name libgcc_s*
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/lib/libgcc_s.so
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/lib/libgcc_s.so.1
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/lib64/libgcc_s.so
/var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/lib64/libgcc_s.so.1

so it doesn't look as if gcc is looking in the right place for libgcc_s.

This problem appears to affect GCC 4.2.0 as well.
Comment 1 Lionel Barnett 2007-06-20 15:31:33 UTC 
(In reply to comment #0)
I can work around this by symlinking:

to ../lib64/libgcc_s.so from /var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2

and:

to ../../lib/libgcc_s.so from /var/scratch/lionelb/usr/gcc-4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/32

Is this advisable?
Comment 2 Jonathan Wakely 2007-07-09 10:30:24 UTC 
I'm seeing the same with this configuration:

Using built-in specs.
Target: x86_64-redhat-linux
Configured with: $SRCS/gcc/gcc-4.1.1/configure --prefix=$DEST/gcc/4.1.1-64bit --with-gnu-as --with-as=$DEST/binutils/2.16.1-64bit/bin/as64 --with-gnu-ld --with-ld=$DEST/binutils/2.16.1-64bit/bin/ld64 --enable-shared --enable-threads=posix --enable-languages=c,c++ --disable-checking --with-system-zlib --enable-__cxa_atexit --enable-version-specific-runtime-libs --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.1

(very long paths substituted for SRCS/DEST for brevity)

libgcc_s cannot be found for either 32-bit (-m32) or 64-bit (-m64) builds, because the appropriate one of $PREFIX/lib/gcc/x86_64-redhat-linux/{lib,lib64} isn't in the linker's list of library paths.

This only happens for multi-libbed compilers; for a 32-bit-only compiler on the same machine there is no problem, because libgcc_s is in the $PREFIX/lib/gcc/x86_64-redhat-linux/4.1.1 directory, which is always in the linker's search path.

Exactly the same problem happens with a multi-libbed 4.1.1 with target sparc64-sun-solaris2.8
Comment 3 Jonathan Wakely 2007-07-09 10:35:39 UTC 
In reply to comment #2:
actually, the sparc64-sun-solaris2.8 problem could be slightly different and I can't confirm it now
Comment 4 Jonathan Wakely 2007-08-03 23:30:04 UTC 
re-confirmed with latest 4.3 snapshot:

tests$ ~/gcc/4.x/bin/g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/jwakely/src/gcc-4.3-20070727/configure
--prefix=/home/jwakely/gcc/4.x --enable-languages=c,c++
--with-mtune=opteron --disable-checking --disable-nls
--disable-libstdcxx-pch --with-system-zlib --with-__cxa_atexit
--disable-bootstrap --with-ld=/opt/binutils/2.16.1-64bit/bin/ld
--with-as=/opt/binutils/2.16.1-64bit/bin/as
--with-gmp=/home/jwakely/gcc/gmp --with-mpfr=/home/jwakely/gcc/mpfr
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.3.0 20070727 (experimental)
tests$
tests$ echo 'int main() {}' > x.cc
tests$ ~/gcc/4.x/bin/g++ x.cc
/opt/binutils/2.16.1-64bit/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status

libgcc_s.so is here:

tests$ find ~/gcc/4.x -name libgcc_s.so
/home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/lib64/libgcc_s.so
/home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/lib/libgcc_s.so

but linker doesn't look in there:

tests$ ~/gcc/4.x/bin/g++ x.cc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/jwakely/src/gcc-4.3-20070727/configure
--prefix=/home/jwakely/gcc/4.x --enable-languages=c,c++
--with-mtune=opteron --disable-checking --disable-nls
--disable-libstdcxx-pch --with-system-zlib --with-__cxa_atexit
--disable-bootstrap --with-ld=/opt/binutils/2.16.1-64bit/bin/ld
--with-as=/opt/binutils/2.16.1-64bit/bin/as
--with-gmp=/home/jwakely/gcc/gmp --with-mpfr=/home/jwakely/gcc/mpfr
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.3.0 20070727 (experimental)

/home/jwakely/gcc/4.x/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/cc1plus
-quiet -v -D_GNU_SOURCE x.cc -quiet -dumpbase x.cc -mtune=generic
-auxbase x -version -o /tmp/ccV5Z2oD.s
ignoring nonexistent directory
"/home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../.
./x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include/c++

/home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include/c++
/x86_64-unknown-linux-gnu

/home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include/c++
/backward
 /usr/local/include
 /home/jwakely/gcc/4.x/include
 /home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include

/home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/include-fix
ed
 /usr/include
End of search list.
GNU C++ version 4.3.0 20070727 (experimental) (x86_64-unknown-linux-gnu)
       compiled by GNU C version 4.2.1, GMP version 4.2.1, MPFR version
2.2.1.
warning: GMP header version 4.2.1 differs from library version 4.1.2.
GGC heuristics: --param ggc-min-expand=100 --param
ggc-min-heapsize=131072
Compiler executable checksum: 9a001b9c39aab973e1c3102a443037d6
 /opt/binutils/2.16.1-64bit/bin/as -V -Qy -o /tmp/cc6Eze17.o
/tmp/ccV5Z2oD.s
GNU assembler version 2.16.1 (x86_64-unknown-linux-gnu) using BFD
version 2.16.1

/home/jwakely/gcc/4.x/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/collect
2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o
/home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtbegin.o
-L/home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.3.0
-L/home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../
../lib64 -L/lib/../lib64 -L/usr/lib/../lib64
-L/home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../..
/tmp/cc6Eze17.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/jwakely/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtend.o
/usr/lib/../lib64/crtn.o
/opt/binutils/2.16.1-64bit/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status

=> --enable-version-specific-runtime-libs is broken ?
Comment 5 Ralf Wildenhues 2008-02-19 18:35:18 UTC 
*** Bug 35248 has been marked as a duplicate of this bug. ***
Comment 6 Ralf Wildenhues 2008-02-21 15:32:59 UTC 
*** Bug 35277 has been marked as a duplicate of this bug. ***
Comment 7 Jonathan Wakely 2008-06-16 11:12:19 UTC 
This has now been broken for at least 3 releases and is going to stay broken in 4.4 at this rate. Could a build maintainer comment on Richard's analysis in bug 35248?  CCing Paolo again.
Comment 8 Daniel Franke 2008-06-30 14:17:14 UTC 
In PR35248, Richard wrote:
> libgcc_s goes into slibdir which is set as
>
> AC_ARG_WITH(slibdir,
> [  --with-slibdir=DIR      shared libraries in DIR [[LIBDIR]]],
> slibdir="$with_slibdir",
> if test "${enable_version_specific_runtime_libs+set}" = set; then
>   slibdir='$(libsubdir)'
> elif test "$host" != "$target"; then
>   slibdir='$(build_tooldir)/lib'
> else
>   slibdir='$(libdir)'
> fi)
> AC_SUBST(slibdir)
> 
> and libsubdir is (should be)
> 
> libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version)
>
> but indeed, the (shared and .so link) libs end up in
> $(libdir)/gcc/$(target_noncanonical)/lib{,64} instead.

In ./gcc/libgcc.mvars, we have

  SHLIB_INSTALL = $(mkinstalldirs) $(DESTDIR)$(slibdir)@shlib_slibdir_qual@; [...]

where $(DESTDIR)$(libdir) seems to be correct for me. However, the last part (@shlib_slibdir_qual@) is substituted in libgcc/Makefile.in(install-shared) with $(MULTIOSSUBDIR) which is based on `$(CC) $(CFLAGS) -print-multi-os-directory)`, here '../lib64'.


Hope this helps and rings a bell with someone ...?!
Comment 9 Peter Anastos 2009-07-14 06:35:17 UTC 
I was about to post this:

--enable-version-specific-runtime-libs is pretty broken:

in the <sysroot>/lib/gcc/x86_64-w64-mingw32 dir, there exists a lib32 and lib64 dir alongside the <version> (i.e. 4.4.1) dir. Neither are searched in by gcc. They contain the core lib libgcc_s.a

Building gcc 4.4.1 with gcc 4.5.0 (might or might not be relevant), there is a 4.5.0 dir created also, where the core crtfastmath.o, libgcc_eh.a, libgcc.a, and libgcov.a libraries are (mis)placed. Obviously that directory is not searched by gcc 4.4.1.
Comment 10 Matt Fago 2011-01-17 19:59:27 UTC 
Still an issue with gcc 4.5.2 release.
Comment 11 Harald van Dijk 2011-08-24 22:29:36 UTC 
(In reply to comment #8)
> In ./gcc/libgcc.mvars, we have
> 
>   SHLIB_INSTALL = $(mkinstalldirs) $(DESTDIR)$(slibdir)@shlib_slibdir_qual@;
> [...]
> 
> where $(DESTDIR)$(libdir) seems to be correct for me. However, the last part
> (@shlib_slibdir_qual@) is substituted in libgcc/Makefile.in(install-shared)
> with $(MULTIOSSUBDIR) which is based on `$(CC) $(CFLAGS)
> -print-multi-os-directory)`, here '../lib64'.

Yes, for --enable-version-specific-runtime-libs, it should be replaced by $(MULTISUBDIR) rather than $(MULTIOSSUBDIR). But $(MULTISUBDIR) would be wrong for the default configuration. Other subdirectories handle this by adding the $(MULTI*) from the configure script instead of the Makefile.in.
Comment 12 Yannick Duchêne (Hibou57) 2013-04-21 23:50:33 UTC 
I can confirm the same with GCC 4.8.0.

With a an i386-linux-gnu host, the bug does not occurs with a cross compiler to i686-linux-gnu, but occurs with a cross compiler to x86-64-linux-gnu.
Comment 13 Hugues de Lassus 2015-12-02 17:57:22 UTC 
For me it affects gcc 5.2.0 compiled for native target x86_64-unknown-linux-gnu as well.
Comment 14 Bruno Haible 2017-01-05 00:21:33 UTC 
I'm seeing this also, with gcc 4.9.0. Configured on x86_64 Linux with
../gcc-4.9.0/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --prefix=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --enable-shared --enable-version-specific-runtime-libs --enable-nls --enable-threads=posix --enable-__cxa_atexit --with-as=/arch/x86_64-linux-gnu/gnu/bin/as --with-gmp=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --with-mpfr=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --with-mpc=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --with-libelf=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --with-isl=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --with-cloog=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --with-ecj-jar=/downloads/sourceware.org-ecj/ecj-latest.jar

The build with --enable-version-specific-runtime-libs fails to find libgcc_s when linking programs. The build without this option works fine.

Analyzing the difference:

* Location of installed libraries other than libgcc_s:
Most 32-bit libraries get installed in
  - PREFIX/lib32 for the working build,
  - PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32 for the build with --enable-version-specific-runtime-libs.
Most 64-bit libraries get installed in
  - PREFIX/lib64 for the working build,
  - PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0 for the build with --enable-version-specific-runtime-libs.

* Location of installed libgcc_s (.so symlink and .so.1):
32-bit libgcc_s gets installed in
  - PREFIX/lib32 for the working build,
  - PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib32 for the build with --enable-version-specific-runtime-libs.
64-bit libgcc_s gets installed in
  - PREFIX/lib64 for the working build,
  - PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib64 for the build with --enable-version-specific-runtime-libs.

* The library path (set of -L options) that collect2 passes to ld, however, is the same in both cases (without and with --enable-version-specific-runtime-libs). Namely:

When creating 32-bit binaries:
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../lib32
/lib/i386-linux-gnu
/lib/../lib32
/usr/lib/i386-linux-gnu
/usr/lib/../lib32
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0
PREFIX/lib/gcc
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../..
/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu

When creating 64-bit binaries:
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0
PREFIX/lib/gcc
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../lib64
/lib/x86_64-linux-gnu
/lib/../lib64
/usr/lib/x86_64-linux-gnu
PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../..

This library path contains the location of all installed libraries except libgcc_s.

Conclusion:

So it looks really like a bug in the installation rules for libgcc_s.
- The 32-bit libgcc_s ought to be installed in PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32, not PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib32.
- The 64-bit libgcc_s ought to be installed in PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0, not PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib64.
Comment 15 Dan Ibanez 2017-06-05 15:10:11 UTC 
It has been 10 years. This is still a problem in GCC 7.1.0.

Either fix it properly or add something that causes configure to fail when that flag is specified.

10 years.
Comment 16 Xi Ruoyao 2017-08-22 01:28:49 UTC 
(In reply to Bruno Haible from comment #14)

> Conclusion:
> 
> So it looks really like a bug in the installation rules for libgcc_s.
> - The 32-bit libgcc_s ought to be installed in
> PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32, not
> PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib32.
> - The 64-bit libgcc_s ought to be installed in
> PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0, not
> PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib64.

But if we do that there would be no PREFIX/lib(64)/libgcc_s.so.1.  Then we
have to add PREFIX/lib/gcc/{arch}/{version}/{multilibdir} to ld.so.conf.  I
think we should create symlink PREFIX/lib(64)/libgcc_s.so.1 as well.
Comment 17 Harald van Dijk 2017-08-22 06:19:37 UTC 
(In reply to Xi Ruoyao from comment #16)
> But if we do that there would be no PREFIX/lib(64)/libgcc_s.so.1.

Indeed, and there shouldn't be. Not providing libgcc* in that location is exactly how --enable-version-specific-runtime-libs used to work.

> Then we
> have to add PREFIX/lib/gcc/{arch}/{version}/{multilibdir} to ld.so.conf.

As mentioned on <https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html>, this option can be used to install multiple versions of GCC side by side. If one version of GCC is built without --enable-version-specific-runtime-libs, that version of GCC provides the version of the libraries to be used at run-time.

Alternatively, indeed, ld.so.conf. Or manually create symlinks.