g++-mike-eh8-C test failure
John David Anglin
dave@hiauly1.hia.nrc.ca
Tue May 2 13:02:00 GMT 2000
> 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.
But if the shared library is complete, we may end up with duplicate code
for __muldi3 and lose anyway. The HP linker is apparently too dumb to
detect this duplication and I have to wonder if shl_load would do much
better.
I doubt the current link command actually produces a complete libstdc++.
I think -lm is needed. There is no shared pa1.1 version of libm under
10.20. So it is possible that there could be problems with duplicating
code here.
Do we really need libstdc++ to work with dlopen/shl_load? If somebody
does, presumably they could build a special dynamically loadable version
and hack libgcc to remove the duplication. They could also define a
table of necessary libgcc routines that the app needs to run. I am
sure somebody could figure out a scheme to do this automatically.
I would argue that there is a simple fix that works with the standard
dynamic loader and thus it should be implemented. I don't think it is
a big issue to tell people about the restrictions of the implementation.
It's definitely a step up from not working at all. We seem to be trying
to run before we can walk.
> 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.
Building a shared libgcc is a good idea on its own. However, it might
not resolve this problem. There still might be duplication of procedures
and problems with libraries that don't have a shared implementation.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
More information about the Gcc-bugs
mailing list