After loading application into memory, dynamic linker loads wine stuff first, then when loading aceutilities.so into memory, pthread symbols are defined in module ntdll.dll.so - already loaded into memory - and so it doesn't try to load libpthread.so, because pthread symbols are already resolved.
Right. Really, you *want* aceutilities.so to use the Wine versions. In theory, it should all work fine except the threads that aceutilities creates are "wine-aware". If it doesn't, that means the Wine pthreads emulation is not perfect yet.
My questions are:
- Why Winelib uses it's own implementation of pthreads (at least it
looks like this is intention)?
Lionel answered that...
- Is it possible to force linker to use symbols from libpthread.so
instead of symbols from ntdll.dll.so? (I don't know how to tell linker to use symbol, e.g. pthread_cond_wait, from specified library, i.e. /lib/libpthread.so.0).
Unfortunately not currently. The symbol fixup semantics of ELF were designed to be easily understandable by old-skool UNIX-heads for whom dynamic linking was enough of a shock to the system as it is. That means despite the dynamic linkage loading model, symbol fixup still uses a static linking model - ie the linker always links a symbol to the first definition found, regardless of the current objects position in the link tree.
This causes all kinds of problems in Linux these days, primarily when two major version of a library are linked into the same process image and conflict.... the "official" solution is to use symbol versioning for everything, as then the symbol is always connected to the correct version at any rate, though it just invents yet another namespace for shlibs to fight over <sigh>
The real solution IMHO is to implement Solaris style group and direct fixup semantics in rtld. The glibc guys do want this, but it's not near the top of their priority list.
thanks -mike (who has a love/hate relationship with ELF :)