On Tue, 9 Feb 2016 21:18:42 -0600 (CST) Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote:
BF> On Tue, 9 Feb 2016, Vadim Zeitlin wrote: BF> > BF> > 2. Enabling this option is not enough as you must also painstakingly add BF> > -no-undefined to all LDFLAGS. Why does libtool need to force you to do BF> > it instead of just using it unconditionally for all MSW DLLs knowing BF> > that they can never have any undefined symbols? While using this BF> > option is a good idea for the other platforms too anyhow, there just BF> > doesn't seem to be any reason to not use it implicitly for MSW, is BF> > there? BF> BF> This is an indication that appropriate steps have been taken to apply BF> all needed dependencies at link time. This is often not the case. Sorry for repeating it again and again but I'd just like to be sure that we all agree about what happens here because I just can't understand how can we disagree about the implications if we agree about the facts. So let's consider a library which doesn't use -no-undefined. If it really has any undefined symbols, libtool will currently build a shared library for it under traditional Unix but (silently!) build a static library under MSW which is bad enough but could be justified by saying that it's the only thing that can be done under MSW in this case (I still disagree with this however and would strongly prefer if libtool gave an error instead if static libraries are disabled, but ignore this for now). But if the library effectively doesn't have any undefined symbols, it would still produce a shared library under Unix and a static one under MSW which is just not logical nor useful at all. I suggest to change libtool to try to produce a DLL under MSW which seems obviously more correct as it's always strictly preferable to the current one: either it will succeed and we'll get what we wanted or it will fail due to undefined symbols (which are disallowed in a DLL) and we'll get an error message. If you disagree with this, could you please explain why? I.e. in which situation exactly (undefined symbols present or not) do you believe the current approach to be superior and why? BF> Systems like GNU/Linux support implicit dependencies and so sometimes BF> an effort is made to not include dependencies, or they may be missed BF> by accident. Well, that's a perfect example of doing things that encourage usages in one dominant platform (Linux) to do things which don't work on another one (MSW)... BF> > 4. After all the previous steps I could finally cajole libtool into BF> > building the DLLs for my lib_LTLIBRARIES but it still silently builds BF> > static libraries for all my noinst_LTLIBRARIES and I have no idea why. BF> BF> These are likely "convenience" libraries which are not used as normal BF> archive libraries at link time. Instead all of the objects are BF> extracted and applied at link time. The archive library is used as a BF> container rather than a normal archive library. I understand this, but it seems strange that it's impossible to build DLLs without having to install them with libtool. The notions of static/shared and installable/not-installable are orthogonal and I don't understand why should libtool conflate them. BF> It is important that change for Windows do not break the many other BF> supported platforms. This goes without saying but everything I mentioned so far wouldn't affect any other platforms at all anyhow. BF> Your changes are welcome if they assure this and improve reliability BF> and usability. OK, I'll try to make some patches. What is the preferred way of submitting them? I ask this because I posted a trivial patch here ~5 years ago (see http://lists.gnu.org/archive/html/libtool-patches/2011-06/msg00001.html) which was never applied, so I also submitted it via Savannah (see https://savannah.gnu.org/patch/?8843) but this didn't seem to help neither, and I'm not really sure what else I can do. Thanks, VZ
pgpiXkPjvTXT4.pgp
Description: PGP signature
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool