On 2/9/16, Vadim Zeitlin <vz-libt...@zeitlins.org> wrote: > On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler <nbow...@draconx.ca> wrote: > NB> Here's the thing. Libtool is, by default, designed to transparently > NB> support the case where building a shared library is not possible. > > 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.
There are still systems where shared library support is limited or not available at all. The most obvious is DOS, which still sees some use. Next is Microsoft Windows (including Cygwin), where building shared libraries is not always possible (for example, if the library contains undefined symbols). Libtool will transparently handles this, by not building shared libraries when it cannot do so. The idea is that packages can still be useful without shared library support. In my experience, this works very well. The -no-undefined option is a signal to libtool: "This library is compatible with systems that don't support undefined symbols in shared libraries". It affects libtool's decision on whether or not a shared library is possible. Cheers, Nick _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
