Bug 14697 - libstdc++ couldn't find 32bit libgcc_s
libstdc++ couldn't find 32bit libgcc_s
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: libstdc++
3.4.0
: P2 normal
: 3.4.2
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-23 17:50 UTC by H.J. Lu
Modified: 2004-07-15 19:12 UTC (History)
2 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:
Last reconfirmed: 2004-03-24 01:12:47


Attachments
A patch to use -shared-libgcc instead of -lgcc_s (649 bytes, patch)
2004-03-23 20:02 UTC, H.J. Lu
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2004-03-23 17:50:53 UTC
When building 32bit libstdc++, I got

checking for shared libgcc... no
configure: WARNING: === You have requested some kind of symbol versioning, but
configure: WARNING: === either you are not using a supported linker, or you are
configure: WARNING: === not building a shared libgcc_s (which is required).
configure: WARNING: === Symbol versioning will be disabled.
configure: versioning on shared library symbols is no 

It is caused by
configure:63426: checking for shared libgcc configure:63452:
/export/build/gnu/gcc-3.4/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-3.4/build-x86_64-linux/gcc/
-B/usr/gcc-3.4/x86_64-unknown-linux-gnu/bin/
-B/usr/gcc-3.4/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/gcc-3.4/x86_64-unknown-linux-gnu/include -isystem
/usr/gcc-3.4/x86_64-unknown-linux-gnu/sys-include  -m32 -o conftest  -lgcc_s -O2
-g -O2  conftest.c -lm  >&5 /usr/local/bin/ld: skipping incompatible
/export/build/gnu/gcc-3.4/build-x86_64-linux/gcc/libgcc_s.so when searching for
-lgcc_s /usr/local/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
Comment 1 Paolo Carlini 2004-03-23 18:28:33 UTC
Hi. I cannot reproduce this in a normal (multilibed) build (c,c++)
(ld version 2.14.90.0.5 20030722)

How did you configure?
Comment 2 H.J. Lu 2004-03-23 18:33:13 UTC
I used

.../gcc-3.4/gcc/configure \
        x86_64-linux \
        --enable-clocale=gnu --with-system-zlib \
         \
        --enable-shared \
        --enable-threads=posix \
        --enable-haifa \
        --disable-checking \
        --prefix=/usr/gcc-3.4 \
        --with-local-prefix=/usr/local
Comment 3 H.J. Lu 2004-03-23 18:49:24 UTC
In libstdc++-v3/acinclude.m4, there are

# Check to see if libgcc_s exists, indicating that shared libgcc is possible.
if test $enable_symvers != no; then
  AC_MSG_CHECKING([for shared libgcc])
  ac_save_CFLAGS="$CFLAGS"
  CFLAGS=' -lgcc_s'
  AC_TRY_LINK(, [return 0;], glibcxx_shared_libgcc=yes, glibcxx_shared_libgcc=no)
  CFLAGS="$ac_save_CFLAGS"
  AC_MSG_RESULT($glibcxx_shared_libgcc)
fi
                                                                                
It won't work with multilib when the name of the shared libgcc is not
libgcc_s.so. On x86_64, it is libgcc_s_32.so. It should use -shared-libgcc
instead of -lgcc_s.
Comment 4 Paolo Carlini 2004-03-23 18:50:46 UTC
Possibly, but the fact is, I'm on x86_64 and works!
Comment 5 Paolo Carlini 2004-03-23 18:58:56 UTC
Indeed, /gcc/*/32/libgcc_s.so.1 !
Comment 6 H.J. Lu 2004-03-23 19:05:01 UTC
Linker won't even look at libgcc_s.so.1 when -lgcc_s is passed down to
it. You must have a 32bit libgcc_s.so somewhere else. Could you please
find out where your 32bit libgcc_s.so comes from? It doesn't exist on
my machine. There is only libgcc_s_32.so. You can add -Wl,--verbose to
CFLAGS in libstdc++-v3/configure and config.log should tell you where
your 32bit libgcc_s.so is.
Comment 7 Paolo Carlini 2004-03-23 19:15:53 UTC
Ok, that would explain it: in my system I have both a /lib/libgcc_s.so.1
and a /lib64/libgcc_s.so.1

If you are sure about the source of problem (indeed, your explanation makes
perfect sense to me!) and its fix, please go ahead, test the patch and post it! 
Comment 8 Paolo Carlini 2004-03-23 19:22:29 UTC
> Ok, that would explain it: in my system I have both a /lib/libgcc_s.so.1
>and a /lib64/libgcc_s.so.1

... and a /lib64/libgcc_s.so ;)
Comment 9 H.J. Lu 2004-03-23 19:37:53 UTC
I do have /lib/libgcc_s.so.1 and /lib64/libgcc_s.so.1. I just
don't have "the 32bit libgcc_s.so", by which I mean a file called
"libgcc_s.so" which contains 32bit shared libgcc.
Comment 10 H.J. Lu 2004-03-23 20:02:28 UTC
Created attachment 5982 [details]
A patch to use -shared-libgcc instead of -lgcc_s
Comment 11 Alexandre Oliva 2004-03-24 01:12:46 UTC
-shared-libgcc is a no-op if GCC is configured with --disable-shared, in which
case the test at hand is meant to fail, but will pass, so the patch is incorrect.
Comment 12 H.J. Lu 2004-03-24 17:45:25 UTC
If gcc is configured with --disable-shared, I don't believe shared libstdc++
will work very well. Symbol versioning will only work with shared library.
There is no poing to check -lgcc_s if gcc is configured with --disable-shared.
Comment 13 Alexandre Oliva 2004-03-24 21:17:10 UTC
--enable/disable-shared is not all-or-nothing.  You can pass a list of packages
to --enable-shared for which you want shared libraries to be enabled. 
--enable-shared=libgcc will get you a shared libgcc, but static libstdc++. 
--enable-shared=libstdc++ will get you a shared libstdc++ while building static
libgcc only.

One of the points of the test at hand is to tell whether libgcc was built as a
shared library.  If it wasn't, enabling symbol versioning would be wrong, since
it doesn't have symbol versions.  After your patch, the test would pass instead
of failing, since gcc will be a do-nothing.  Therefore, your patch breaks the
test.  It's wrong.
Comment 14 Benjamin Kosnik 2004-05-13 21:50:06 UTC
H.J., what's the status on this? And, just out of curosity, what linux distro
are you using on x86_64?

-benjamin
Comment 15 H.J. Lu 2004-05-18 23:19:36 UTC
I haven't got the time to work on it. I am running RHEL 3 U2 and Fedora Core 2.
Comment 16 CVS Commits 2004-07-15 17:38:51 UTC
Subject: Bug 14697

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	jakub@gcc.gnu.org	2004-07-15 17:38:46

Modified files:
	libstdc++-v3   : ChangeLog acinclude.m4 configure 

Log message:
	PR libstdc++/14697
	* acinclude.m4 (glibcxx_shared_libgcc): Correct
	glibcxx_shared_libgcc test for multilibs.
	* configure: Rebuilt.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2577&r2=1.2578
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/acinclude.m4.diff?cvsroot=gcc&r1=1.293&r2=1.294
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/configure.diff?cvsroot=gcc&r1=1.400&r2=1.401

Comment 17 CVS Commits 2004-07-15 17:43:07 UTC
Subject: Bug 14697

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	jakub@gcc.gnu.org	2004-07-15 17:43:05

Modified files:
	libstdc++-v3   : ChangeLog acinclude.m4 configure 

Log message:
	PR libstdc++/14697
	* acinclude.m4 (glibcxx_shared_libgcc): Correct
	glibcxx_shared_libgcc test for multilibs.
	* configure: Rebuilt.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.2224.2.143&r2=1.2224.2.144
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/acinclude.m4.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.280.4.5&r2=1.280.4.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/configure.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.373.4.16&r2=1.373.4.17

Comment 18 Andrew Pinski 2004-07-15 19:12:08 UTC
Fixed for 3.4.2.