On 2/10/16, Vadim Zeitlin <vz-libt...@zeitlins.org> wrote: > On Wed, 10 Feb 2016 10:23:00 -0500 Nick Bowler <nbow...@draconx.ca> wrote: > NB> On 2/9/16, Vadim Zeitlin <vz-libt...@zeitlins.org> wrote: > NB> > On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler <nbow...@draconx.ca> > 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 _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool