[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re[4]: MSW DLLs support in libtool
From: |
Nick Bowler |
Subject: |
Re: Re[4]: MSW DLLs support in libtool |
Date: |
Wed, 10 Feb 2016 10:51:02 -0500 |
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
- Re: MSW DLLs support in libtool, (continued)
- Re: MSW DLLs support in libtool, Evgeny Grin, 2016/02/10
- Re: MSW DLLs support in libtool, Nick Bowler, 2016/02/10
- Re: MSW DLLs support in libtool, Evgeny Grin, 2016/02/10
- Re: MSW DLLs support in libtool, Evgeny Grin, 2016/02/10
- Re: MSW DLLs support in libtool, Evgeny Grin, 2016/02/10
- Re: Re[2]: MSW DLLs support in libtool, Nick Bowler, 2016/02/10
- Re[4]: MSW DLLs support in libtool, Vadim Zeitlin, 2016/02/10
- Re: Re[4]: MSW DLLs support in libtool,
Nick Bowler <=
- Re[6]: MSW DLLs support in libtool, Vadim Zeitlin, 2016/02/10
- Re: MSW DLLs support in libtool, Evgeny Grin, 2016/02/11
- Re: MSW DLLs support in libtool, Bob Friesenhahn, 2016/02/11
- Re: MSW DLLs support in libtool, Evgeny Grin, 2016/02/12
- Re: MSW DLLs support in libtool, Evgeny Grin, 2016/02/10
Re: MSW DLLs support in libtool, Bob Friesenhahn, 2016/02/09
Re: MSW DLLs support in libtool, Bob Friesenhahn, 2016/02/09