libstdc++/4455: HP-UX - libstdc++.sl depends on libgcc.a
david.keegan@marconi.com
david.keegan@marconi.com
Wed Oct 3 07:16:00 GMT 2001
>Number: 4455
>Category: libstdc++
>Synopsis: HP-UX - libstdc++.sl depends on libgcc.a
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Oct 03 07:16:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: David Keegan
>Release: gcc-3.0.1
>Organization:
>Environment:
HPUX 11.00 gcc-3.0.1 binutils-2.11.2 hppa1.1-hp-hpux11
>Description:
The shared version of libstdc++ that is built on
HP-UX 11.00 with gcc-3.0.1/binutils-2.11.2 has
several unresolved symbols (_Unwind_SjLj_Register etc)
that would have been resolved by linking it with
libgcc.a.
When attempting to link my own shared library
containing C++ code these symbols remain unresolved
even though -lgcc is in the link command both before
and after -lstdc++ and even if the +n option is passed
to the HP-UX linker. There are no warnings when my
shared library is being linked, but when one of its
functions is called it aborts due to the unresolved
symbols in libstdc++.
I can work around this by using the -Fl link option to
force all of libgcc.a into my shared library, but it is
hardly an acceptable solution.
Should libstdc++.sl not have been linked against libgcc.a
in the first place to resolve these symbols? How can I
make this happen?
>How-To-Repeat:
Build a shared library with C++ code containing
new char[n]/delete[] and link with -lstdc++ option.
>Fix:
Use -Wl,-Fl,<path>/libgcc.a to force in all of libgcc.a
when linking the shared library.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the Gcc-prs
mailing list