2009/10/14 Michael Matz
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.
I understand.
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.
I have unpacked glibc sources and... I'm scared :-p (being unable to easily install kscope because of some stupid dependency issues doesn't help). So, if no one here has time and capacity to look into this probably the best thing to do would be to raise the problem upstream. Should I? I heard scary stories about Drepper ;-) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org