From mboxrd@z Thu Jan  1 00:00:00 1970
From: david.keegan@marconi.com
To: gcc-gnats@gcc.gnu.org
Subject: libstdc++/4455: HP-UX - libstdc++.sl depends on libgcc.a
Date: Wed, 03 Oct 2001 07:16:00 -0000
Message-id: <20011003140850.26151.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-10/msg00037.html
List-Id: <gcc-prs.sourceware.org>

>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: