Re: g++-mike-eh8-C test failure

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> 4. Build a shared libgcc and have it referenced by either the main program
> or the library.  Which is precisely what we're discussing in another thread.

I hacked the gcc Makefile to build a shared version of libgcc under hpux
10.20.  This was relatively simple to do since all the modules in libgcc
for this target are already PIC.  I did have to change the "-BstageN/"
stuff to "-B$(objdir)/stageN/" so that the compiler would work outside
the gcc build directory.  This resolves the g++-mike-eh8-C and other
related failures in the g++ testsuite.  There were no test regressions
that I could see for any of the other testsuites.

My hacks certainly aren't ready for prime time but they suggest a possible
way to proceed.  There are issues such as versioning and the installation
process which I haven't given much thought to.  Typically, hpux applications
need to be relinked with the installed library before installation.
There is also the question as to whether the dependence of libgcc.sl on
libc should be explicit or not.  The same issue applies to libstdc++.
For most targets, an explicit dependence is specified for libm but not
libc.

I would highly encourage trying to get the build process modified to support
building a shared version of libgcc for the next release.  I am really unhappy
about linking the archive version of libgcc into the shared version libstdc++.

The are a couple of problems that I have noted in the lib and link specs
for pa1.1 machines under hpux 10.20.  The -L libraries for -p and -pg
should preceed the  -L specs for the pa1.1 libraries in the link spec.
Under 10.20, libc_r.sl is just a link to libc in /usr/lib.  There is no
archive version of libc_r.  I don't know about other releases of hpux 10,
but I think this suggests that "-lc" could be used as the lib spec for all
!shared cases.  If libc_r and libc differ on other releases, then libc_r
will still have to be specified for thread usage.  There are subtle issues
regarding which libc is used with a shared libgcc if the dependence on
libc is explicit.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)