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

[Peter Rosin]

Den 2011-06-17 01:15 skrev Bob Friesenhahn:
> On Thu, 16 Jun 2011, Vadim Zeitlin wrote:
>> BF>
>> BF> In what way was libtool specifically requested to build a DLL?
>>
>> I'm not sure about the details (please keep in mind that we're speaking
>> about libxml2 here and not my own project) but configure[*] is passed
>> --disable-static option and AFAIK this is handled by AM_PROG_LIBTOOL as
>> meaning that [only] shared libraries should be built, isn't it?
> 
> It does seem like falling back to building a static library when 
> --disable-static has been specified is a bug.
> 
>> IOW I don't think an example when proceeding ahead is a viable solution is
>> possible. Do you have anything concrete in mind?
> 
> As it happens, GCC under MinGW and Cygwin does have an "auto-import" facility
> which magically allows it to work for code built with GCC. Explicit
> dllexport/dllimport is not needed. It does not work for MSVC and might
> not work if GCC is linking against a MSVC-built DLL/library.

Hrmm, hrmm, allow me to step into this conversation and make a note that
there are libraries that work just fine in all kinds of ways when built
with MSVC. Libtool can with those libraries produce both a static and a
shared library and you can write applications that need not know, at
compile time, if they are going to be linked with the shared or the
static library. And it's not that difficult either. Heck, I can do it :-)

Granted, you will probably(?) take an extra pointer dereference if you
are actually linking with the static library, but it works. The libtool
testsuite would have more fails with MSVC if this was not the case.

>> BF> If libtool simply refuses to proceed, then many applications will fail
>> BF> to build and users will also be unhappy.
>>
>> Again, I don't think such change could break anything because applications
>> that would rely on this behaviour wouldn't build even right now.
> 
> I have experienced such issues before but my own application did still build 
> and work.
> 
> A library which is expected to be loaded by another program such as a DLL or
> loadable module would obviously be broken by static linkage.

Yes, I agree, there are obviously cases where a static lib does not
fill the shoes of a shared lib...

Cheers,
Peter