Bug 233714

Summary: gcc 3.2.3-56 ld error on hidden symbol `_Unwind_GetIPInfo'
Product: Red Hat Enterprise Linux 3 Reporter: Martin Sebor <sebor>
Component: gcc3Assignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 3.0Keywords: Reopened
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: https://issues.apache.org/jira/browse/STDCXX-369
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-05-30 19:49:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Martin Sebor 2007-03-23 22:47:07 UTC
gcc 3.2.3-56 but not gcc 3.2.3-53 exhibits the problem below which makes it
impossible to link programs with a shared Apache C++ standard library:

$ cat t.cpp && gcc -c -fpic t.cpp && gcc t.o -lsupc++ -shared -o libfoo.so &&
gcc -c -DMAIN t.cpp && gcc t.o -v -L. -lfoo -lsupc++
#ifdef MAIN
void foo (int);
int main () { foo (0); }
#else
void foo (int i) { throw i; }
#endif
Reading specs from
/package/1/compilers/gcc-3.2.3-56/bin/../lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure
--prefix=/nfs/packages/mdx/rhas/compilers/gcc-3.2.3-56
--mandir=/nfs/packages/mdx/rhas/compilers/gcc-3.2.3-56/man
--infodir=/nfs/packages/mdx/rhas/compilers/gcc-3.2.3-56/info --enable-shared
--enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-56)
 /package/1/compilers/gcc-3.2.3-56/bin/../lib/gcc-lib/i386-redhat-linux/3.2.3/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o
/usr/lib/crti.o
/package/1/compilers/gcc-3.2.3-56/bin/../lib/gcc-lib/i386-redhat-linux/3.2.3/crtbegin.o
-L.
-L/package/1/compilers/gcc-3.2.3-56/bin/../lib/gcc-lib/i386-redhat-linux/3.2.3
-L/package/1/compilers/gcc-3.2.3-56/bin/../lib/gcc-lib
-L/nfs/packages/mdx/rhas/compilers/gcc-3.2.3-56/lib/gcc-lib/i386-redhat-linux/3.2.3
-L/package/1/compilers/gcc-3.2.3-56/bin/../lib/gcc-lib/i386-redhat-linux/3.2.3/../../..
-L/nfs/packages/mdx/rhas/compilers/gcc-3.2.3-56/lib/gcc-lib/i386-redhat-linux/3.2.3/../../..
t.o -lfoo -lsupc++ -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/package/1/compilers/gcc-3.2.3-56/bin/../lib/gcc-lib/i386-redhat-linux/3.2.3/crtend.o
/usr/lib/crtn.o
/package/1/utils/binutils-2.14.90.0.4-42/bin/ld: a.out: hidden symbol
`_Unwind_GetIPInfo' in
/package/1/compilers/gcc-3.2.3-56/bin/../lib/gcc-lib/i386-redhat-linux/3.2.3/libgcc_eh.a(unwind-dw2.oS)
is referenced by DSO
collect2: ld returned 1 exit status

Comment 1 Jakub Jelinek 2007-03-24 08:46:59 UTC
You need to build C++ shared libraries either with g++ or with gcc
-shared-libgcc.

Comment 2 Martin Sebor 2007-04-03 21:51:29 UTC
We can't link our C++ standard library with g++ -- we'd get ORD violations.

I can give -lgcc (I assume that's what you meant) a try but that's not how we've
ever built our shared libraries (whether on Linux, HP-UX, IRIX, Solaris, or any
other platform) with any version of gcc (starting with 2.95.2 all the way up to
4.1). This is the first and only time we've had the problem.

Comment 3 Martin Sebor 2007-05-16 23:16:02 UTC
I see you actually did mean -shared-libgcc. That works, thanks! I'm still not
convinced that's how we're supposed to be using the compiler. Can you give us a
pointer to an FAQ or a thread on a GCC list where this is explained? (I have
reopened the issue until this is cleared up.)

Comment 4 Martin Sebor 2007-05-16 23:30:58 UTC
I should probably clarify that I've read the section of the gcc manual on linking
and that I'm looking for more detail, specifically how do we know when using the
option is safe and recommended and when it may not be. We support many versions
of gcc on many platforms and this is the first time we have come across this
option, so please understand our reluctance to simply add a new option without
fully understanding the impact.

http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Link-Options.html#index-shared_002dlibgcc-514

Comment 5 Jakub Jelinek 2007-05-30 19:49:38 UTC
I think the manual you referenced in the URL is very obvious on it.
If you link C++ or Java code into a shared library or executable (except -static
link), you should use the g++ (resp. gcj) driver or link with gcc
-shared-libgcc, unless you know you don't need the unwinder (that would be e.g.
if all the C++ code was compiled with -fno-exceptions).
For C-only code, unless you use -fexceptions and pthread_cleanup_{push,pop},
the default is ok.
In GCC 3.4.0 and above when configured with recent enough binutils
when neither -shared-libgcc nor -static-libgcc is present, gcc driver will link
with libgcc_s.so if the shared library or executable needs the unwinder,
otherwise will link only with libgcc.a.
See http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02210.html
for more details.