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