MSW DLLs support in libtool

[Vadim Zeitlin]

 Hello,

 I'd like to create Windows binaries for my software from Linux, which
includes creating a couple of DLLs and EXEs that use them. This is not too
difficult to do with just manual makefiles as both the cross-compiler and
linker work just fine. Libtool is another matter entirely however:

1. By default, libtool _silently_ doesn't create DLLs at all and
   "win32-dll" LT_INIT() option needs to be used just to give it a chance
   to fail. This default looks very unfortunate to me, static libraries are
   almost never the right replacement for the DLLs and finding this option
   when you don't know about it already is not obvious. I'd strongly prefer
   if this option were enabled by default but failing that libtool should
   at least give a noticeable warning if the target platform is MSW and it
   is not enabled and require using no-win32-dll explicitly to disable it.

2. Enabling this option is not enough as you must also painstakingly add
   -no-undefined to all LDFLAGS. Why does libtool need to force you to do
   it instead of just using it unconditionally for all MSW DLLs knowing
   that they can *never* have any undefined symbols? While using this
   option is a good idea for the other platforms too anyhow, there just
   doesn't seem to be any reason to not use it implicitly for MSW, is
   there?

3. If you thought that making the two changes above would be enough to
   finally create the DLLs instead of static libraries, as I did, you would
   be wrong because if any of the DLLs link with any static libraries, it
   will still create static libraries (albeit not silently this time)
   because it fails to check if it can link link the DLL with these static
   libraries. This is extremely frustrating because it has absolutely no
   reason to be checking for anything at all, unlike some other platforms
   (e.g. Linux x86-64), there are no restrictions whatsoever on the
   libraries that the DLLs can be linked with as they don't need to contain
   PIC code under MSW. After some digging around I could work around this
   by doing "lt_cv_deplibs_check_method=pass_all" in configure before
   LT_INIT() but this was far from obvious to find and, of course, not
   guaranteed to work in the future. Why isn't "pass_all" the default (and
   only possibility) for the MSW targets?

4. After all the previous steps I could finally cajole libtool into
   building the DLLs for my lib_LTLIBRARIES but it still silently builds
   static libraries for all my noinst_LTLIBRARIES and I have no idea why.
   I'm giving up for now because this is less critical, but it would still
   need to be fixed if I want to continue using libtool instead of just
   abandoning it (and, by necessity, automake) and going back to hand
   written makefiles.

 The most aggravating thing is that libtool really seems to go out of its
way to make MSW DLLs creation more difficult than it needs to be with all
the tests for things that can never happen. I realize that DLLs are very
different from the typical Unix shared libraries which are libtool's bread
and butter, but surely they're important enough in practice to have some
special handling for them?

 If libtool has a goal of providing decent support for MSW DLLs, I could
try submitting patches changing the things above to work in a more
user-friendly way, but I'd really like to know if they would be welcome
first or if, perhaps, the way things [don't] work now is a subtle hint that
libtool just shouldn't be used if first-tier MSW support is required.

 Thanks in advance for any thoughts,
VZ

pgpinjSiDKfu9.pgp
Description: PGP signature