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> wrote:
NB> > NB> Here's the thing. Libtool is, by default, designed to transparently
NB> > NB> support the case where building a shared library is not possible.
NB> >
NB> > This is, IMO, an obsolete principle to follow. I admit it made sense in
NB> > the 90s when I first started using libtool and some proprietary Unix
NB> > systems didn't have support for shared libraries or, at least, didn't have
NB> > support for them in libtool.
NB>
NB> There are still systems where shared library support is limited or not
NB> available at all. The most obvious is DOS, which still sees some 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.
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. 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.
NB> Libtool will transparently handles this, by not building shared
NB> libraries when it cannot do so. The idea is that packages can
NB> still be useful without shared library support. In my experience,
NB> this works very well.
In my experience it works horribly. Actually, it just doesn't work.
NB> The -no-undefined option is a signal to libtool: "This library is
NB> compatible with systems that don't support undefined symbols in shared
NB> libraries". It affects libtool's decision on whether or not a shared
NB> library is possible.
First of all, this is not even the way it currently works (see points (1)
and (3) of my original message). Second, while philosophically defensible,
this point of view is just singularly unhelpful in practice. As I keep
saying, assuming no-undefined for MSW DLLs would result in better outcomes
in all situations. If I'm missing some situation in which it would be
wrong, nobody has pointed it out yet.
Regards,
VZ
pgpI1uVcEkfOJ.pgp
Description: PGP signature
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
