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

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

>   In message <200004301546.LAA19936@hiauly1.hia.nrc.ca>you write:
>   > After all this grief with duplicate routines, I decided to change the
>   > hpux configuration for libstdc++ so that the standard libraries are not
>   > linked into libstdc++.sl.  This resolves the problem.
> And just adds a new set of problems.  Consider if the library needs something
> like __muldi3 -- you won't have it anymore after your change because you're
> not linking in libgcc.
> 
> Basically you've just exchanged one set of problems for an even worse set
> of problems.

No.  "-nostdlib" is only used when building the shared varsion of libstdc++.
When an app is linked with libstdc++, libgcc is normally included twice in
the link (eg., without threads -lgcc -lc -lgcc is automatically included).
With the change, I didn't encounter any link problems using the shared
version of libstdc++ included with the gcc-2.95 branch except for the
one case mentioned which involved threads and profiling.  I am fairly
certain if __muldi3 weren't being linked in from libgcc properly,
something would have gone wrong in running the testsuite.  The results 
with a shared libstdc++ were equivalent to that with the archive version.
Thus, I don't see the worse set of problems that you describe with the
hpux 10.20 linker.  Have you a specific example that I can test?

NB: I have installed the longjmp patch to pa.md which is now in the main
branch but not the 2.95 branch, and a configure patch re DCE thread selection
which fixes linking problems when DCE threads are installed.  Thus, some
of the problems previously observed may be fixed.

The situation here is specific to the hpux som linker and its handling
of global data in shared libraries.  If libstdc++ is linked with libgcc
when it is built, this has the unfortunate side effect of linking static
procedures into a final app twice, once from libstdc++ and once from
libgcc.  Both get used.  Which one is selected depends on the calling
path.  If the routine has data which shouldn't be duplicated, disaster
ensues.  In the particalur case studied, it was the global data symbol
"__tic" which caused tinfo2.o to be loaded from libgcc rather than
libstdc++.

Possible solutions as I see it are:

1)	Get HP to fix their linker.  Doesn't seem likely.

2)	Hack libstdc++ so that global data is only accessed in procedures
	with global scope.  This is possible but more complicated than
	3 below.

3)	Don't link the shared version of libstdc++ with libgcc when it
	is built.  I know there were problems on other systems (alpha?)
	when this was done.  This needs to be looked into further under
	hpux but if you check the configuration files for libstdc++ you
	will see that openbsd uses the -nostdlib option when building
	the shared version of libstdc++.

In summary, with the above mentioned patches installed in the gcc-2.95 branch,
I find that the shared libstdc++ v2 is working equivalently to the archive
version.

The situation with the main branch is now under investigation.  However, it
looks like there are other problems which need resolution first.

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