Re: Re[4]: MSW DLLs support in libtool

[Nick Bowler]

On 2/10/16, Vadim Zeitlin <address@hidden> wrote:
> On Wed, 10 Feb 2016 10:23:00 -0500 Nick Bowler <address@hidden> wrote:
> NB> On 2/9/16, Vadim Zeitlin <address@hidden> wrote:
> NB> > On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler <address@hidden>
> NB> > wrote:
> NB> > NB> Here's the thing.  Libtool is, by default, designed to
> NB> > NB> transparently support the case where building a shared library
> NB> > NB> is not possible.
> NB> >
> NB> > This is, IMO, an obsolete principle to follow. I admit it made
> NB> > sense in the 90s when I first started using libtool and some
> NB> > proprietary Unix systems didn't have support for shared
> NB> > libraries or, at least, didn't have support for them in
> NB> > libtool.
> NB>
> NB> There are still systems where shared library support is limited or
> NB> available at all.  The most obvious is DOS, which still sees some
> NB> use.
>
> We can disagree about this, but I just don't think it's reasonable to
> create static libraries instead of DLLs under MSW out of concern for
> DOS.

The default (on all platforms) is to create both static libraries and,
when possible, shared libraries.

> NB> Next is Microsoft Windows (including Cygwin), where building shared
> NB> libraries is not always possible (for example, if the library contains
> NB> undefined symbols).
>
> The request to build a DLL with undefined symbols should result in an
> error, not "successfully" building a static library.

If you explicitly request a shared library (i.e., call libtool in
link mode with the -shared option), and it is not possible, you should
receive an error.  If this is not happening, then this is probably a
bug in libtool.

> Again, I can understand that there can be some doubt about the default
> behaviour here and some people may believe that it's better to build
> anything at all rather than failing. I completely disagree with this
> because IMNSHO a low level tool such as libtool should do what it's
> told ("create a shared library") instead of what it thinks would be
> best. But it seems completely obvious to me that creating static
> libraries when disable-static is used is nothing more than a bug.

If libtool is creating static libraries by default when configured with
--disable-static, then that certainly seems like a libtool bug.  I just
tested it, and the option works as expected for me.  Can you provide
a test case?

Note that it is still possible to explicitly request static libraries:
the -static option to libtool will supersede the configure option (as
documented).

Cheers,
  Nick