On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler <nbow...@draconx.ca> wrote:
NB> On 2/9/16, Vadim Zeitlin <vz-libt...@zeitlins.org> wrote: NB> > I'd like to create Windows binaries for my software from Linux, which NB> > includes creating a couple of DLLs and EXEs that use them. This is not too NB> > difficult to do with just manual makefiles as both the cross-compiler and NB> > linker work just fine. Libtool is another matter entirely however: NB> > NB> > 1. By default, libtool silently doesn't create DLLs at all and NB> > "win32-dll" LT_INIT() option needs to be used just to give it a chance NB> > to fail. This default looks very unfortunate to me, static libraries NB> > are almost never the right replacement for the DLLs and finding this NB> > option when you don't know about it already is not obvious. I'd NB> > strongly prefer if this option were enabled by default but failing that NB> > libtool should at least give a noticeable warning if the target NB> > platform is MSW and it is not enabled and require using no-win32-dll NB> > explicitly to disable it. NB> NB> Here's the thing. Libtool is, by default, designed to transparently NB> support the case where building a shared library is not possible. Hi, This is, IMO, an obsolete principle to follow. I admit it made sense in the 90s when I first started using libtool and some proprietary Unix systems didn't have support for shared libraries or, at least, didn't have support for them in libtool. But this is simply not the case any more since many, many years and there are just no more systems where building shared libraries is impossible in common use any longer. But this is a separate story. NB> If you don't want to build static libraries, configure with NB> --disable-static. Then you will get errors whenever building NB> a shared library is not possible. I'm awfully sorry, I forgot to mention this in my post, but I do use disable-static in LT_INIT(). The behaviour of libtool with respect to MSW DLLs would still be wrong, IMHO, even without this option because it's completely unexpected, but it could at least be argued to be compatible with the letter, if not the spirit, of its documentation. But this is not how it works in practice, making it even worse. FWIW I'm using libtool 2.4.2 currently, but I looked at the changes in the latest git and I didn't notice anything that seemed related to this. In any case, once again, giving an error with disable-static would be better, but not by much: instead of building static libraries, you now wouldn't be able to build anything at all. At the very least, disable-static should be changed to imply win32-dll. NB> > 2. Enabling this option is not enough as you must also painstakingly add NB> > -no-undefined to all LDFLAGS. Why does libtool need to force you to do NB> > it instead of just using it unconditionally for all MSW DLLs knowing NB> > that they can never have any undefined symbols? While using this NB> > option is a good idea for the other platforms too anyhow, there just NB> > doesn't seem to be any reason to not use it implicitly for MSW, is NB> > there? NB> NB> Because unless you tell it, libtool has no way to know a priori whether NB> a library will have undefined symbols or not. Sorry but this is just not true for the MSW DLLs. If the libtool user tries to build a DLL, you can safely assume that it will not have undefined symbols. Anything else just doesn't make sense because it would always result in an error. Again, this is different from the traditional Unix shared libraries. NB> In retrospect, the default (assume undefined symbols are possible) was NB> probably a bad choice, because undefined symbols in libraries are rarely NB> used. Thus, almost all libraries need to specify -no-undefined. But NB> this can't be changed now without causing regressions. Yes, I understand this and this is why I didn't propose changing it even if I absolutely agree that it's the wrong default. But I still think it should be implicit for MSW DLLs because there is no danger of regressions in this particular case. NB> > 3. If you thought that making the two changes above would be enough to NB> > finally create the DLLs instead of static libraries, as I did, you would NB> > be wrong because if any of the DLLs link with any static libraries, it NB> > will still create static libraries (albeit not silently this time) ... NB> The nasty warning when you link shared libraries against static libtool NB> libraries is because this arrangement is not portable, and libtool is NB> designed to facilitate portable packages. I could accept the warning if it then went ahead with creating the DLL, but falling back to creating a static library because a check the result of which is known in advance (spoiler: it passes) couldn't be performed just makes no sense. NB> If you still want to do it anyway, the warnings can be avoided by NB> passing libtool the .a file directly. Better to use shared libtool NB> libraries (or libtool convenience libraries) if at all possible. In this particular case, I do use a libtool convenience library but, for unrelated reasons, I don't want to build that particular 3rd party library as a DLL under MSW (it is built as a shared library under Linux). So right now I simply have no solution to this problem. NB> > 4. After all the previous steps I could finally cajole libtool into NB> > building the DLLs for my lib_LTLIBRARIES but it still silently builds NB> > static libraries for all my noinst_LTLIBRARIES and I have no idea why. NB> > I'm giving up for now because this is less critical, but it would still NB> > need to be fixed if I want to continue using libtool instead of just NB> > abandoning it (and, by necessity, automake) and going back to hand NB> > written makefiles. NB> NB> These libraries are libtool convenience libraries. They are a bit NB> different from normal libraries, as they cannot be installed (they are NB> little more than a way to avoid passing a whole bunch of object NB> filenames to libtool when linking). I understand this but I still don't understand why doesn't libtool create DLLs for them. I have several tests which are not installed and I'd like them to use the same DLL instead of linking all of them with the static (convenience) library. There doesn't seem to be any way of achieving this currently. But you're right, this is not MSW-specific as I wrongly assumed, so let's forget about this point. NB> > If libtool has a goal of providing decent support for MSW DLLs, I NB> > could try submitting patches changing the things above to work in a NB> > more user-friendly way, but I'd really like to know if they would be NB> > welcome first or if, perhaps, the way things [don't] work now is a NB> > subtle hint that libtool just shouldn't be used if first-tier MSW NB> > support is required. NB> NB> TBH I'm not sure what problem you are actually having. But I imagine NB> patches to improve things are always welcome. Well, my patches would be incompatible with the philosophy aimed at doing things not making sense for any modern system just to have a chance to warn you that you're doing something that might not work on some completely different (and obsolete) system, so I'm not really sure about this. To be precise, I'd like to: 0. Ensure that static libraries are never created when shared ones are explicitly requested. 1. Turn win32-dll on by default. If there are really any objections to this, at least turn it on by default if disable-static is used because not doing it in this case is completely nonsensical. 2. Don't check for -no-undefined when creating MSW DLLs because we may safely assume it is true in this case. 3. Don't check whether we can link a DLL with another library because we already know that we always can do this. For me personally (3) is by far the most important point as I have already wasted time due to (0), (1) and (2) and now I know about them, so I only want to fix this to help the others avoid doing the same. As I said, this might not conform to the original libtool philosophy, but pragmatically speaking, this would make libtool much more user-friendly to people who use it to create DLLs. Which, of the philosophy and usability, is more important for libtool? VZ
pgpJ8M7BL9xoc.pgp
Description: PGP signature
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool