Re[2]: MSW DLLs support in libtool

[Vadim Zeitlin]

On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler <address@hidden> wrote:

NB> On 2/9/16, Vadim Zeitlin <address@hidden> 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

pgpfKnssANLTB.pgp
Description: PGP signature