Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Charles Wilson]

On 6/23/2011 11:03 AM, Vadim Zeitlin wrote:
> On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn <address@hidden> 
> 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