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
Hi. I cannot reproduce this in a normal (multilibed) build (c,c++) (ld version 2.14.90.0.5 20030722) How did you configure?
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
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.
Possibly, but the fact is, I'm on x86_64 and works!
Indeed, /gcc/*/32/libgcc_s.so.1 !
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.
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!
> 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 ;)
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.
Created attachment 5982 [details] A patch to use -shared-libgcc instead of -lgcc_s
-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.
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.
--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.
H.J., what's the status on this? And, just out of curosity, what linux distro are you using on x86_64? -benjamin
I haven't got the time to work on it. I am running RHEL 3 U2 and Fedora Core 2.
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
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
Fixed for 3.4.2.