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

[Bob Friesenhahn]

On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
> 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?

It does seem like falling back to building a static library when 
--disable-static has been specified is a bug.

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

As it happens, GCC under MinGW and Cygwin does have an "auto-import" 
facility which magically allows it to work for code built with GCC. 
Explicit dllexport/dllimport is not needed. It does not work for MSVC 
and might not work if GCC is linking against a MSVC-built DLL/library.

> 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.

I have experienced such issues before but my own application did still 
build and work.

A library which is expected to be loaded by another program such as a 
DLL or loadable module would obviously be broken by static linkage.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/