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

[Vadim Zeitlin]

On Thu, 16 Jun 2011 15:36:24 -0500 (CDT) Bob Friesenhahn <address@hidden> wrote:

BF> On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
BF> > different functions (_foo vs imp_foo). So IMO creating a static library
BF> > when libtool was requested to build a DLL is never the right thing to do
BF> > under Windows. And while I hesitate to call this behaviour a bug because 
it
BF> > is clearly intentional, I'd like to see it changed because it would have
BF> > saved me (and presumably others) a lot of time if libtool simply stopped
BF> > with an error after giving the above message instead of valiantly but
BF> > ultimately counterproductively trying to continue.
BF> 
BF> In what way was libtool specifically requested to build a DLL?

 I'm not sure about the details (please keep in mind that we're speaking
about libxml2 here and not my own project) but configure[*] is passed
--disable-static option and AFAIK this is handled by AM_PROG_LIBTOOL as
meaning that [only] shared libraries should be built, isn't it?

BF> There are certainly cases where proceeding ahead with a static library 
BF> is a viable solution.

 Sorry, I can't agree with this when speaking about _Windows_ libraries.
While under a typical Unix system you can link a program with either static
or shared library without changing anything in its code, this is not the
case under Windows as you must either use __declspec(dllimport) or
equivalent or not use it (usually this is governed by some preprocessor
symbols similar to libxml2 LIBXML_STATIC so you need to either define or
not define it). So if the project expects to link with a DLL, producing a
static library is not helpful as linking with it would still fail -- and in
fact this is exactly what happens in my case. Notice that, on the contrary,
if the project can link with a static library then it wouldn't be able to
link with a DLL and so it wouldn't be trying to build it using libtool in
the first place.

 IOW I don't think an example when proceeding ahead is a viable solution is
possible. Do you have anything concrete in mind?

BF> If libtool simply refuses to proceed, then many applications will fail
BF> to build and users will also be unhappy.

 Again, I don't think such change could break anything because applications
that would rely on this behaviour wouldn't build even right now.

BF> What happens if you specify --disable-static to configure?  Does that 
BF> help?

 No, --disable-static is already used, in fact, sorry for failing to
mention it in my original message.

 Thanks for your reply,
VZ

[*] See http://git.gnome.org/browse/libxml2/tree/configure.in

pgpf4XYqBxNSk.pgp
Description: PGP signature