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
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool
