Bug 233714 - gcc 3.2.3-56 ld error on hidden symbol `_Unwind_GetIPInfo'
gcc 3.2.3-56 ld error on hidden symbol `_Unwind_GetIPInfo'
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gcc3 (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-03-23 18:47 EDT by Martin Sebor
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-30 15:49:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Martin Sebor 2007-03-23 18:47:07 EDT
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); }
void foo (int i) { throw i; }
Reading specs from
Configured with: ../configure
--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)
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o
t.o -lfoo -lsupc++ -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/package/1/utils/binutils- a.out: hidden symbol
`_Unwind_GetIPInfo' in
is referenced by DSO
collect2: ld returned 1 exit status
Comment 1 Jakub Jelinek 2007-03-24 04:46:59 EDT
You need to build C++ shared libraries either with g++ or with gcc
Comment 2 Martin Sebor 2007-04-03 17:51:29 EDT
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 19:16:02 EDT
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 19:30:58 EDT
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.

Comment 5 Jakub Jelinek 2007-05-30 15:49:38 EDT
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.