Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 233714 - gcc 3.2.3-56 ld error on hidden symbol `_Unwind_GetIPInfo'
Summary: gcc 3.2.3-56 ld error on hidden symbol `_Unwind_GetIPInfo'
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gcc3
Version: 3.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL: https://issues.apache.org/jira/browse...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-23 22:47 UTC by Martin Sebor
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-05-30 19:49:38 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.