Re: MSW DLLs support in libtool

[Nick Bowler]

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

Here's the thing.  Libtool is, by default, designed to transparently
support the case where building a shared library is not possible.

If you don't want to build static libraries, configure with
--disable-static.  Then you will get errors whenever building
a shared library is not possible.

If your package absolutely does not support static libraries at all, you
can pass disable-static to LT_INIT (or controlled on a per-library basis
with -shared).  Nobody will be able to build your package where shared
libraries are not possible.

> 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?

Because unless you tell it, libtool has no way to know a priori whether
a library will have undefined symbols or not.  In order to transparently
fall back to static libraries in this case libtool requires this
information.

In retrospect, the default (assume undefined symbols are possible) was
probably a bad choice, because undefined symbols in libraries are rarely
used.  Thus, almost all libraries need to specify -no-undefined.  But
this can't be changed now without causing regressions.

> 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?

The nasty warning when you link shared libraries against static libtool
libraries is because this arrangement is not portable, and libtool is
designed to facilitate portable packages.

If you still want to do it anyway, the warnings can be avoided by
passing libtool the .a file directly.  Better to use shared libtool
libraries (or libtool convenience libraries) if at all possible.

> 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.

These libraries are libtool convenience libraries.  They are a bit
different from normal libraries, as they cannot be installed (they are
little more than a way to avoid passing a whole bunch of object
filenames to libtool when linking).

[snip]

> 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.

TBH I'm not sure what problem you are actually having.  But I imagine
patches to improve things are always welcome.

Cheers,
  Nick