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 _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool