This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: g++-mike-eh8-C test failure
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Subject: Re: g++-mike-eh8-C test failure
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 02 May 2000 12:17:25 -0600
- cc: jason at cygnus dot com, gcc-patches at gcc dot gnu dot org, egcs-bugs at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <200005021808.OAA18067@hiauly1.hia.nrc.ca>you write:
> No. "-nostdlib" is only used when building the shared varsion of libstdc++
And that is precisely the problem. That change is _wrong_, no ifs ands or
butts about it.
> 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.
Consider a shared library that does not appear on the link line, but which
is loaded explicitly by the application.
If the shared library references __muldi3, but the main application and
libraries on the link line for the application do not, then no __main will
be linked into the final executable.
So when you do a shl_load to suck in the shared library we'll have an
undefined reference to __muldi3 and we'll lose badly.
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?
See above.
Never assume that just because something passes the testsuite that it is
correct. There are numerous things the testsuite does not check.
> 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++.
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.
jeff