On Tue, 9 Feb 2016, Vadim Zeitlin wrote:
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?
This is an indication that appropriate steps have been taken to apply all needed dependencies at link time. This is often not the case. Systems like GNU/Linux support implicit dependencies and so sometimes an effort is made to not include dependencies, or they may be missed by accident.
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.
These are likely "convenience" libraries which are not used as normal archive libraries at link time. Instead all of the objects are extracted and applied at link time. The archive library is used as a container rather than a normal archive library.
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?
There is special handling. You already reported the -no-undefined special handling. :-)
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.
It is important that change for Windows do not break the many other supported platforms. Your changes are welcome if they assure this and improve reliability and usability.
There is a long-standing principle in the history of libtool that it should provide consistent functionality across platforms and not do things which encourage usages in one dominant platform which do not work on the others.
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