On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote:
BF> On Fri, 17 Jun 2011, Vadim Zeitlin wrote: BF> > BF> > Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just BF> > too accustomed to the "traditional" Windows way and have trouble accepting BF> > auto-import magic. It's true that projects using auto-import could live BF> > with falling back to a static library. But consider that auto-importing is BF> > relatively new so there should be proportionally few projects using it, BF> > hence IMHO the risk of breakage remains reasonably small. BF> 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 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. Anyhow, this is purely anecdotal and it's going to be hard to find an objective way of determining whether it's the case. 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)? What do you think? VZ
pgprs6Kf8Ckas.pgp
Description: PGP signature
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool