Re[2]: MSW DLLs support in libtool

[Vadim Zeitlin]

On Tue, 9 Feb 2016 21:18:42 -0600 (CST) Bob Friesenhahn <address@hidden> 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

pgpIfZYhvtApj.pgp
Description: PGP signature