Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Charles Wilson]

On 6/17/2011 10:19 AM, Vadim Zeitlin wrote:
> On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn <address@hidden> 
> wrote:
> BF> Most projects using libtool come from Unix/Linux where "auto-import" 
> BF> is the default so it can be seen that most projects already depend on 
> BF> it
> 
>  My personal experience seems to contradict it. Maybe because auto-import
> is relatively recent

It was developed back in 2000, and all cygwin and mingw compilers since
that date have supported it, EXCEPT for the old msys gcc-2.95.1 toolkit
which was used to create *msys* executables up until 2009.

> or maybe because most originally Unix projects that
> target Windows (meaning not only Cygwin but usually MinGW as well and
> sometimes even MSVC) need to fix other Windows-specific issues anyhow and
> so do make the relatively small extra effort to add the necessary declspecs
> too. 

This.  IF -- and usually ONLY if -- the upstream maintainers have ported
to *msvc* FIRST, then they have added the declspec stuff.  Then, when it
comes to supporting mingw, they have a choice: do things "the unix way"
and DON'T activate the declspec stuff and use autoimport instead, OR, do
things "the MSVC way".

My experience has been that this decision usually goes the win32 way,
but a significant fraction go the unix way for mingw.

The alternate path is this: the upstream maintainers port to mingw
FIRST, and fix the obvious things like using _mkdir(one arg) instead of
mkdir(two, args) -- but don't want to "uglify" their headers with
declspec.  THEN, they port to msvc and are forced to uglify.  At that
point, they have a new choice: do they retrofit the declspec stuff for
their existing mingw build, or not.  Most do not.

Obviously, packages developed originally on/for windows have the
declspec stuff, and usually keep it "turned on" for msvc and mingw.

>  Anyhow, this is purely anecdotal and it's going to be hard to find an
> objective way of determining whether it's the case.

True.

>  A more interesting question is if the current situation with libtool can
> be improved because I continue to believe that getting a static library
> when you're trying to build a shared one can be very unexpected. And this
> can be the case even under Unix where there would be presumably too much
> resistance to change the way --disable-static works if it is controversial
> even under Windows where I thought it would be "obviously correct".
> 
>  So it seems the only solution with any chance of acceptance would be to
> add a different option doing what I want, e.g. --enable-shared-only. Or
> maybe allow --enable-shared=(yes|no|only)?

No, I think --disable-static, if specified, should actually *disable
static*.  That should be sufficient.

If it's not doing that, then it's a bug IMO.

--
Chuck