On Tue, 13 Oct 2009, Cristian Morales Vega wrote:
Couldn't this be fixed through symbol versioning?
Note that what I know
about this is what I have just read and some quick tests.
Right now both libc and libpthread export "open@@GLIBC_2.0". Could not
libpthread instead (or also) export "open@@PTHREAD_2.9"?
For some functions that would possibly work, a library or application
using just 'open' and link-edited against libpthread would use
open@@PTHREAD, an app only link-edited against libc would use open@@GLIBC.
This works as long as there's no other function that relies on the
specific behaviour of e.g. open. Now imagine a pair of functions a and b,
that need to be called in pairs (like open/close) where both must either
come from libc or from libpthread when used on the same object, and
imagine that one is called from a library, the other from the app, hence
using a@@GLIBC vs. b@@PTHREAD, and kaboom, again you have the error
open/close don't have this problem (as said they do the same thing with
linux glibc and libpthread), neither do flockfile/funlockfile (despite
what I said earlier they also do the same thing in both libs, I didn't
check carefully enough), but I'm not sure if there aren't other pairs with
this behaviour as I didn't look at all of the common symbols.
Now that so many of the functions turn out to do the same thing perhaps it
would be worthwhile if somebody looked at each of the common ones to
determine where real differences are left to explain the dead-locks we see
occasionally. Perhaps we can get rid of them by some small extensions in
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org