On 6/23/2011 11:03 AM, Vadim Zeitlin wrote: > On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn > <bfrie...@simple.dallas.tx.us> wrote: > > BF> On Thu, 23 Jun 2011, Vadim Zeitlin wrote: > BF> > > BF> > I.e. it created a shared library with undefined symbols without any > BF> > problems because it never actually passed -no-undefined to g++/ld. > BF> > BF> In actual practice, it seems difficult or impossible to build programs > BF> under systems like Linux with -no-undefined. > > I didn't know this but doesn't this make the situation even worse? I.e. > because of the above you can't even recommend people to use -no-undefined > by default. So the default behaviour will remain the current one, i.e. no > DLLs at all under Windows.
No, what it means is that, IF the project maintainers want to support shared libraries (DLLs) on win32, then they must do the following -- and this is true regardless of whether libtool is involved. 1) Ensure that when building for win32, that the various object files that will be combined into the DLL, as well as the library dependencies (-lwhatever) are such that there WILL BE no undefined symbols, at least *when building for win32*. Otherwise, ld will refuse to create the DLL. This may involve restructuring the code, and possibly changing the division of labor between various DLLs if your project has multiple interdependent ones. It is *very* difficult to build stuff on win32 where you have circular dependencies between DLLs, or between DLLs and an EXE -- not impossible, just very difficult. (*) Now, if you are going to go thru all that trouble to support win32...you'd just be making a lot of extra work for yourself to maintain TWO separate library structures -- one for win32 (and, btw, AIX) where everything is "no undefined symbols" clean, and one for everything else where undefined symbols are allowed. So...most projects that end up in this place (**), finally decide to restructure their shared libraries for *ALL* platforms. Notice I haven't said anything about libtool yet. 2) Once you've gone thru the exercise in #1, now you might as well add -no-undefined unconditionally to your libtool invocation -- if you are using libtool, that is. Remember, all the stuff in #1 is required just to build DLLs on win32 *at all*, libtool or no libtool. (*) You basically have to create an export file for DLL A (or the EXE), and an import lib for it. THEN, you can build DLL B as normal, and specify -lDLLA (or -lEXE). Finally, you build the "real" DLL A (or EXE), and specify -lDLLB. Libtool has /no/ direct mechanism to support this. (**) Except for those that use a "plugin" architecture, where the plugin DLLs *must* be able to call back to the EXE. That's really tricky, and they usually end up using another solution, of which there are several (see http://edll.sourceforge.net/ for a good description of several different approaches). But that's outside the scope of our discussion here. -- Chuck _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool