[opensuse-packaging] Re: --as-needed and pthread
Hi, [including some random mailing list, so that the text isn't lost :) ] On Thu, 18 Jun 2009, Cristian Rodríguez wrote:
there are some packages that fail to build because they miss phtread symbols. I have always have the doubt about why there is the "-pthread" gcc flag... somewhere I read that's the correct thing to do, that using -lpthread is wrong, but without explanations. What should I use in these cases? I suppose use -lpthread would be the equivalent to what they did without --as-needed... but perhaps the behavior without --as-needed was already wrong.
matz is the right person to answer your question, as far as I know, the right way is using -lpthread instead of -pthread , is that correct ?
Nope, -pthread is better than -lpthread (see below). It's completely possible that something is broken with as-needed vs. pthreads. Those cases have to be identified and then worked around (export SUSE_AS_NEEDED=0), or better, analyzed for the root cause. I didn't get the complete thread, only this forward, so I don't know what the nature of the breakage is, so I can give only speculations: I would think that if something with pthread and as-needed breaks it doesn't get exposed as missing symbols or the like (so that apps don't even start) but rather mysterious breakages related to non-thread-aware functions being used even though -pthread was given as compile and link flag. [background] Regarding the explanation of -pthread/-lpthread: Unfortunately the initial threading support for UNIX was a bit like bolted onto the existing (non thread-aware) libc. For various reasons it was decided that users that aren't interested in threading are not supposed to pay the cost of _potential_ thread safety. This cost is mostly associated with locking some shared data structures for libc and the process output (e.g. output of printf() ). Now, given this criteria, there's not much choice. Basically the user has to announce to the system if or if not the application is thread aware, so that it (the system) can chose between thread-aware or non thread-aware functions. This announcement is done by the -pthread flag. The difference to the -lpthread flag is that it is not only a link time flag (saying that the libpthread library has to be put into the dependence libraries) but also a compile time flag. So for compiling .c to .o files for a thread aware program it's necessary to include -pthread into the compile flags. The effect of that option is system dependend. Usually it will result in the compiler defining some preprocessor symbols (_REENTRANT) so that system headers can choose between different implementations of various posix functions (where the API doesn't make a difference between thread-safe and -unsafe functions) and internal data structures. So, for memoizing the difference: -lpthread is a link time only flag, simply telling the linker to include libpthread into the application. -pthread (without the "l") is a link time _and compile time flag_. Because sometimes different code has to be emitted (for the runtime system including libc) for programs supposed to be thread-safe, this can't be announced only at the link phase, the compiler has to know about this. [more magic] Now, for linux there's a bit magic involved. To make the cost for non thread-safe programs really low some routines in libc _are not thread-safe_. That's fine, those programs aren't linked against libpthread, so they have announced to be not interested in threads. libpthread.so provides thread-aware variants of some functions that are also provided by libc itself. For instance open() and friends is such function. The libpthread variant includes some locking for shared data structures. (Apart from these overriding functions it also includes the usual pthread functions, pthread_*, e.g. pthread_spin_lock). How this all works is because ELF symbols resolution rules say so. If an application calls "open" and is linked against libpthread and libc (which both provide a version of "open", one thread-aware the other not) then the dynamic linker will chose the first it finds. Other things (gcc .spec files) make sure that libpthread is linked in _before_ libc when -pthread is given. This can't be ensured for -lpthread, the latter being simply a request for a random other library, as far as the system knows. So only -pthread, not -lpthread, makes really sure that libpthread is linked at the right place vs. libc, so that it can override the non thread-aware functions of it. [less magic] Having said all this, it usually is just fine to simply link against libpthread (via -lpthread) with linux, as long as you don't mention -lc before. This is because most headers don't care about the _REENTRANT preprocessor define, i.e. they don't change their content depending on the flag, and because ELF rules will still make the functions from libpthread be preferred. But for cross-platform compatibility it's important to use -pthread, _not_ -lpthread. And as it's important for others, and at least good under linux, you can just as well use it always if you need. Ciao, Michael.
Good explanation. 2009/6/19 Michael Matz <matz@suse.de>:
Hi,
[including some random mailing list, so that the text isn't lost :) ]
On Thu, 18 Jun 2009, Cristian Rodríguez wrote:
there are some packages that fail to build because they miss phtread symbols. I have always have the doubt about why there is the "-pthread" gcc flag... somewhere I read that's the correct thing to do, that using -lpthread is wrong, but without explanations. What should I use in these cases? I suppose use -lpthread would be the equivalent to what they did without --as-needed... but perhaps the behavior without --as-needed was already wrong.
matz is the right person to answer your question, as far as I know, the right way is using -lpthread instead of -pthread , is that correct ?
Nope, -pthread is better than -lpthread (see below). It's completely possible that something is broken with as-needed vs. pthreads. Those cases have to be identified and then worked around (export SUSE_AS_NEEDED=0), or better, analyzed for the root cause.
I didn't get the complete thread, only this forward, so I don't know what the nature of the breakage is, so I can give only speculations: I would think that if something with pthread and as-needed breaks it doesn't get exposed as missing symbols or the like (so that apps don't even start) but rather mysterious breakages related to non-thread-aware functions being used even though -pthread was given as compile and link flag.
They are just link failures... because "-lpthread" is before the object code that uses it (I didn't saw the -lpthread and though there were some magic happening). If there is any problem using -pthread with --as-needed I understand it would be because libc would be linked before libpthread, true? If so, a "ldd -u -r" would say libpthread is an unneeded direct dependency? Would be an easy way to detect it. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2009/6/19 Cristian Morales Vega <cmorve69@yahoo.es>:
If there is any problem using -pthread with --as-needed I understand it would be because libc would be linked before libpthread, true? If so, a "ldd -u -r" would say libpthread is an unneeded direct dependency? Would be an easy way to detect it.
The ldd thing.... obviously no, pthread also provides symbols that libc doesn't. I should sleep more... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2009/6/19 Michael Matz <matz@suse.de>:
Now, for linux there's a bit magic involved. To make the cost for non thread-safe programs really low some routines in libc _are not thread-safe_. That's fine, those programs aren't linked against libpthread, so they have announced to be not interested in threads. libpthread.so provides thread-aware variants of some functions that are also provided by libc itself. For instance open() and friends is such function. The libpthread variant includes some locking for shared data structures.
(Apart from these overriding functions it also includes the usual pthread functions, pthread_*, e.g. pthread_spin_lock).
How this all works is because ELF symbols resolution rules say so. If an application calls "open" and is linked against libpthread and libc (which both provide a version of "open", one thread-aware the other not) then the dynamic linker will chose the first it finds. Other things (gcc .spec files) make sure that libpthread is linked in _before_ libc when -pthread is given. This can't be ensured for -lpthread, the latter being simply a request for a random other library, as far as the system knows. So only -pthread, not -lpthread, makes really sure that libpthread is linked at the right place vs. libc, so that it can override the non thread-aware functions of it.
Looking to some .pc (pkg-config) files I though about this... -pthread can make sure that libpthread is linked in before libc, ok. But what happens if I compile a library with -pthread and then use it from a program that doesn't uses libpthread? Wouldn't in this case the library use the symbols from libc? I though that this could be fixed if every library that uses libpthread adds -pthread to the CFlags in its .pc file (so the program will link against libpthread even if it doesn't uses it). But if I'm using --as-needed this would not work. You said: "Other things (gcc .spec files) make sure that libpthread is linked in _before_ libc when -pthread is given". But this doesn't solves the problem at runtime. There is also any special exception in ld.so so libpthread is always loaded before libc? Even if libpthread is only used by a library deep in the dependency tree and not in the main binary? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Mon, 12 Oct 2009, Cristian Morales Vega wrote:
Looking to some .pc (pkg-config) files I though about this... -pthread can make sure that libpthread is linked in before libc, ok. But what happens if I compile a library with -pthread and then use it from a program that doesn't uses libpthread? Wouldn't in this case the library use the symbols from libc?
And this is exactly what happens sometimes. A program is not thread-aware, loads some plugin which does use threads (and is linked against libpthread), et voila, you get a heap of interesting and hard to diagnose locking issues, usually resulting in dead locks of the program.
I though that this could be fixed if every library that uses libpthread adds -pthread to the CFlags in its .pc file (so the program will link against libpthread even if it doesn't uses it). But if I'm using --as-needed this would not work.
Right. It usually works to have it only in some strategic libs because most programs aren't multi-threaded I guess. See below.
You said: "Other things (gcc .spec files) make sure that libpthread is linked in _before_ libc when -pthread is given". But this doesn't solves the problem at runtime. There is also any special exception in ld.so so libpthread is always loaded before libc?
Nope.
Even if libpthread is only used by a library deep in the dependency tree and not in the main binary?
Now thinking about this, you seem to have a point. A grave point even. If the application itself isn't linked to libpthread (but to libc, which all of them are) then libc will _always_ come before libpthread in symbol search order, for all further symbol lookups. Even from dependency shared libs. So in effect the thread-aware versions will never be used in that scenario. I just verified this behaviour (lib against libpthread, app against lib but not libpthread, lib uses one of the double symbols, and voila, the ones from libc are picked up, not the ones from libpthread). Uhoh. Hmm. I think we're screwed. Applications itself, when there's even a slightest chance of some of its libraries using threads plus the problematic libc functions, must be linked against libpthread; without --as-needed getting rid of it. It's not enough if some core toolkit library links against libpthread, it must be the top-level app. I guess we're not seeing much more of these problems, because if threads are used at all, then probably not the problematic libc functions, or if then not in contexts where it matters. A bit fragile to rely upon this, as it's non-trivial to define the problematic set. It's not as easy as those symbols which are exported by libc as well as by libpthread. E.g. __open and __open64 in both libraries do the same thing. But e.g. flockfile is indeed a noop in libc, and does locking in libpthread. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, Oct 13, 2009 at 2:15 AM, Michael Matz <matz@suse.de> wrote:
Hi,
On Mon, 12 Oct 2009, Cristian Morales Vega wrote:
Looking to some .pc (pkg-config) files I though about this... -pthread can make sure that libpthread is linked in before libc, ok. But what happens if I compile a library with -pthread and then use it from a program that doesn't uses libpthread? Wouldn't in this case the library use the symbols from libc?
And this is exactly what happens sometimes. A program is not thread-aware, loads some plugin which does use threads (and is linked against libpthread), et voila, you get a heap of interesting and hard to diagnose locking issues, usually resulting in dead locks of the program.
I though that this could be fixed if every library that uses libpthread adds -pthread to the CFlags in its .pc file (so the program will link against libpthread even if it doesn't uses it). But if I'm using --as-needed this would not work.
Right. It usually works to have it only in some strategic libs because most programs aren't multi-threaded I guess. See below.
You said: "Other things (gcc .spec files) make sure that libpthread is linked in _before_ libc when -pthread is given". But this doesn't solves the problem at runtime. There is also any special exception in ld.so so libpthread is always loaded before libc?
Nope.
Even if libpthread is only used by a library deep in the dependency tree and not in the main binary?
Now thinking about this, you seem to have a point. A grave point even. If the application itself isn't linked to libpthread (but to libc, which all of them are) then libc will _always_ come before libpthread in symbol search order, for all further symbol lookups. Even from dependency shared libs. So in effect the thread-aware versions will never be used in that scenario. I just verified this behaviour (lib against libpthread, app against lib but not libpthread, lib uses one of the double symbols, and voila, the ones from libc are picked up, not the ones from libpthread). Uhoh.
Hmm. I think we're screwed. Applications itself, when there's even a slightest chance of some of its libraries using threads plus the problematic libc functions, must be linked against libpthread; without --as-needed getting rid of it. It's not enough if some core toolkit library links against libpthread, it must be the top-level app.
I guess we're not seeing much more of these problems, because if threads are used at all, then probably not the problematic libc functions, or if then not in contexts where it matters. A bit fragile to rely upon this, as it's non-trivial to define the problematic set. It's not as easy as those symbols which are exported by libc as well as by libpthread. E.g. __open and __open64 in both libraries do the same thing. But e.g. flockfile is indeed a noop in libc, and does locking in libpthread.
BTW, exists almost an implementation, called "yarn lock", that permit more portability between platform and pthread implementation. Some product, that aim at more cross-platform that was in the past, already use it http://www.mail-archive.com/rpm-cvs@rpm5.org/msg04187.html Regards
Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Tue, 13 Oct 2009, yersinia wrote:
BTW, exists almost an implementation, called "yarn lock",
Well, that's simply a wrapper around pthread, with the intent of it being an abstraction layer for different threading libraries. Given that pthread is POSIX that seems a bit superfluous to do. In any case it doesn't help the slightest with the problem at hand. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2009/10/13 Michael Matz <matz@suse.de>:
Hi,
On Mon, 12 Oct 2009, Cristian Morales Vega wrote:
Looking to some .pc (pkg-config) files I though about this... -pthread can make sure that libpthread is linked in before libc, ok. But what happens if I compile a library with -pthread and then use it from a program that doesn't uses libpthread? Wouldn't in this case the library use the symbols from libc?
And this is exactly what happens sometimes. A program is not thread-aware, loads some plugin which does use threads (and is linked against libpthread), et voila, you get a heap of interesting and hard to diagnose locking issues, usually resulting in dead locks of the program.
I though that this could be fixed if every library that uses libpthread adds -pthread to the CFlags in its .pc file (so the program will link against libpthread even if it doesn't uses it). But if I'm using --as-needed this would not work.
Right. It usually works to have it only in some strategic libs because most programs aren't multi-threaded I guess. See below.
You said: "Other things (gcc .spec files) make sure that libpthread is linked in _before_ libc when -pthread is given". But this doesn't solves the problem at runtime. There is also any special exception in ld.so so libpthread is always loaded before libc?
Nope.
Even if libpthread is only used by a library deep in the dependency tree and not in the main binary?
Now thinking about this, you seem to have a point. A grave point even. If the application itself isn't linked to libpthread (but to libc, which all of them are) then libc will _always_ come before libpthread in symbol search order, for all further symbol lookups. Even from dependency shared libs. So in effect the thread-aware versions will never be used in that scenario. I just verified this behaviour (lib against libpthread, app against lib but not libpthread, lib uses one of the double symbols, and voila, the ones from libc are picked up, not the ones from libpthread). Uhoh.
Hmm. I think we're screwed. Applications itself, when there's even a slightest chance of some of its libraries using threads plus the problematic libc functions, must be linked against libpthread; without --as-needed getting rid of it. It's not enough if some core toolkit library links against libpthread, it must be the top-level app.
I guess we're not seeing much more of these problems, because if threads are used at all, then probably not the problematic libc functions, or if then not in contexts where it matters. A bit fragile to rely upon this, as it's non-trivial to define the problematic set. It's not as easy as those symbols which are exported by libc as well as by libpthread. E.g. __open and __open64 in both libraries do the same thing. But e.g. flockfile is indeed a noop in libc, and does locking in libpthread.
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"? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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
On 10/14/2009 at 8:11, Michael Matz <matz@suse.de> wrote: 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.
Sorry to hijack this thread (a little.. it's snot entirely offtopic, but I admit I do not understand half of what you guys say :) ). I've seen some dead-locks in simple-ccsm (a python app, with a native lib, libcompizconfig linked). Especially on slower notebooks I have trouble loading the app (sometimes it works, most of the time it fails). On the fast system I never experienced an issue with it. Could this be a consequence of such an issue as stated in this thread? Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Wed, 14 Oct 2009, Dominique Leuenberger wrote:
Sorry to hijack this thread (a little.. it's snot entirely offtopic, but I admit I do not understand half of what you guys say :) ). I've seen some dead-locks in simple-ccsm (a python app, with a native lib, libcompizconfig linked). Especially on slower notebooks I have trouble loading the app (sometimes it works, most of the time it fails). On the fast system I never experienced an issue with it. Could this be a consequence of such an issue as stated in this thread?
% ldd /usr/bin/python linux-vdso.so.1 => (0x00007fffe4bff000) libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 (0x00007f04e357a000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f04e335e000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f04e315a000) libutil.so.1 => /lib64/libutil.so.1 (0x00007f04e2f57000) libm.so.6 => /lib64/libm.so.6 (0x00007f04e2d01000) libc.so.6 => /lib64/libc.so.6 (0x00007f04e29a8000) /lib64/ld-linux-x86-64.so.2 (0x00007f04e3912000) libpthread before libc.so.6, hence no, this isn't an effect of what we discussed about. Deadlocks have many reasons ;-) [insert standard rant about threads] Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2009/10/14 Michael Matz <matz@suse.de>:
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
On Thu, 15 Oct 2009 21:42:08 +0200 Cristian Morales Vega <cmorve69@yahoo.es> wrote:
probably the best thing to do would be to raise the problem upstream. Should I? I heard scary stories about Drepper ;-)
You could just consider eglibc upstream. That nicely solves the Drepper-problem. -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 15 Oct 2009, Cristian Morales Vega wrote:
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).
You don't want to look at the glibc sources to initially determine this. It's non-trivial to determine which source files are actually compiled into glibc depending on the configuration, and which headers are actually used to define some of the macros used in sources (that can expand to different things, again depending on configuration). For differences I looked at the dis-assembly of the functions in question. The list of double symbols that possibly matter is below. Some of the symbols are just aliases to each other. And after looking at the asm differences (or non-differences) I referred back to the sources to see if that made sense.
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 ;-)
You don't want to raise this with Drepper in this state. What do you want to ask him? "Hey, sometimes we see dead-locks, libpthread loaded later, but most functions do the same in both libs, do you know what's the cause?". He'll just laugh at you. Ciao, Michael.
Hi, On Fri, 16 Oct 2009, Michael Matz wrote:
looked at the dis-assembly of the functions in question. The list of double symbols that possibly matter is below.
Now it is. Ciao, Michael. -- _IO_flockfile _IO_ftrylockfile _IO_funlockfile __close __connect __errno_location __fcntl __fork __h_errno_location __libc_allocate_rtsig __libc_current_sigrtmax __libc_current_sigrtmin __lseek __nanosleep __open __open64 __pread64 __pwrite64 __read __res_state __send __sigaction __vfork __wait __write accept close connect fcntl flockfile fork fsync ftrylockfile funlockfile longjmp lseek lseek64 msync nanosleep open open64 pause pread pread64 pwrite pwrite64 raise read recv recvfrom recvmsg send sendmsg sendto sigaction siglongjmp sigwait system tcdrain vfork wait waitpid write -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2009/10/16 Michael Matz <matz@suse.de>:
Hi,
On Thu, 15 Oct 2009, Cristian Morales Vega wrote:
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).
You don't want to look at the glibc sources to initially determine this. It's non-trivial to determine which source files are actually compiled into glibc depending on the configuration, and which headers are actually used to define some of the macros used in sources (that can expand to different things, again depending on configuration). For differences I looked at the dis-assembly of the functions in question. The list of double symbols that possibly matter is below. Some of the symbols are just aliases to each other. And after looking at the asm differences (or non-differences) I referred back to the sources to see if that made sense.
Sorry, my assembly knowledge is near zero. I even tried looking at open(), but I would have said libc and libpthread implementations are different... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (5)
-
Cristian Morales Vega -
Dominique Leuenberger -
Michael Matz -
Stefan Seyfried -
yersinia