From mboxrd@z Thu Jan 1 00:00:00 1970 From: "John David Anglin" To: law@cygnus.com Cc: jason@cygnus.com, gcc-patches@gcc.gnu.org, egcs-bugs@egcs.cygnus.com Subject: Re: g++-mike-eh8-C test failure Date: Tue, 02 May 2000 13:02:00 -0000 Message-id: <200005022002.QAA18227@hiauly1.hia.nrc.ca> References: <20404.957291445@upchuck> X-SW-Source: 2000-05/msg00119.html > 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)