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 3:46 AM, Marco atzeri wrote:
> on cygwin
> 
> "lt_cv_deplibs_check_method=pass_all"
> 
> is my workaround at configure stage to bypass incorrect
> libtool detection of system capabilities and to allow
> shared libs building.

It's not about "system capabilities" in this case. It's about the fact
that this -- creating a shared library by linking against existing
static libraries -- is a really bad idea.

If any of those static libs (a) exports a data item, and (b) is used by
more than one DLL in your stack, then you'll end up with two different
copies of the data item, and one DLL will use the first copy while the
other DLL will use the second copy.

Similarly, if the static lib even has a private "global" data item (that
is, not exposed to clients, but used in common by many of the static
lib's API functions), then you end up with the same problem.  The first
DLL will call one copy of those functions, which modify/access the first
instance of this "private global data", while the second DLL will call
the second copy of those functions, which modify/access the second
instance of this "private global data".

Imagine if the data item was a mutex.

IIRC elf can put these "static" elements in a .common section of each
.so, and the elf loader will consolidate them at runtime.  Not so with
pe/coff and the windows loader.

--
Chuck