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
pgppR7k3ZSlcv.pgp
Description: PGP signature
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
