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

[Bob Friesenhahn]

On Fri, 17 Jun 2011, Vadim Zeitlin wrote:


Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just
too accustomed to the "traditional" Windows way and have trouble accepting
auto-import magic. It's true that projects using auto-import could live
with falling back to a static library. But consider that auto-importing is
relatively new so there should be proportionally few projects using it,
hence IMHO the risk of breakage remains reasonably small.


Most projects using libtool come from Unix/Linux where "auto-import" 
is the default so it can be seen that most projects already depend on 
it (and the main issue for them is to use --no-undefined so libtool 
will build a DLL).  Primarily programs which originated under Windows 
(or really care about Windows) use the dllexport/dllimport facilities.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

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

[Vadim Zeitlin]

On Thu, 16 Jun 2011 18:15:01 -0500 (CDT) Bob Friesenhahn 
 wrote:

BF> On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
BF> > BF>
BF> > BF> In what way was libtool specifically requested to build a DLL?
BF> >
BF> > I'm not sure about the details (please keep in mind that we're speaking
BF> > about libxml2 here and not my own project) but configure[*] is passed
BF> > --disable-static option and AFAIK this is handled by AM_PROG_LIBTOOL as
BF> > meaning that [only] shared libraries should be built, isn't it?
BF> 
BF> It does seem like falling back to building a static library when 
BF> --disable-static has been specified is a bug.

 I didn't think about it from this point of view but now that I do, I can't
help but agree with you ;-)

BF> > IOW I don't think an example when proceeding ahead is a viable solution is
BF> > possible. Do you have anything concrete in mind?
BF> 
BF> As it happens, GCC under MinGW and Cygwin does have an "auto-import" 
BF> facility which magically allows it to work for code built with GCC. 

 Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just
too accustomed to the "traditional" Windows way and have trouble accepting
auto-import magic. It's true that projects using auto-import could live
with falling back to a static library. But consider that auto-importing is
relatively new so there should be proportionally few projects using it,
hence IMHO the risk of breakage remains reasonably small.

 Anyhow, logically I think there are 3 possible behaviours for libtool:

1. Build static library.
2. Try to build shared library but fall back to static if it failed.
3. Build shared library and give an error if it failed.

 As you wrote, --disable-static would seem to imply (3). If (2) is really
wanted (and I'm still sceptical about it as the set of projects using
auto-import and for which building a DLL is expected, for some reason, to
fail should be very small) it seems like another option is needed, e.g.
--prefer-shared, to choose it.

 Regards,
VZ


pgpDjG6HV5XKB.pgp
Description: PGP signature
___
https://lists.gnu.org/mailman/listinfo/libtool