couple of questions about pthreads (scheduler/pthread.c) in
mike at theoretic.com
Fri Jun 13 13:39:33 CDT 2003
> 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:
> 1) Why Winelib uses it's own implementation of pthreads (at least it
> looks like this is intention)?
Lionel answered that...
> 2) 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.
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
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 :)
More information about the wine-devel