Hi, 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 situation. 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 glibc. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org