On Sun, 2004-11-14 at 18:46 -0500, Daniel Eischen wrote: > On Sun, 14 Nov 2004, Sean McNeil wrote: > > > > > I think pthread_equal should be added to libc. I found it is used in > > libxml2 and a link to that library fails without -pthread. > > The pthread_foo() in libc are mainly for libc usage. If applications > want to use pthread_foo(), they really should be linking to the (a) > threads library. Look at it this way -- if we didn't use any pthread > functions in libc, there wouldn't be _any_ pthread stubs in libc. > Also, we could have used __libc_lock(), __libc_unlock(), etc, in > libc and have the threads libraries override those functions instead > of using _pthread_*(). > > pthread_equal() would be kinda harmless in libc, but you get my > point above, no? After some thought, I agree as pthread_equal is not used within libc, but this brings up the question as to why there are any pthread_* symbols in libc. This is kind of a sore point for me. I actually believe that there should be no weak symbols of pthread_* in libc. A program that uses pthread_cond_init, for example, should not compile without the pthread library. weak symbols to the _pthread_* functions are fine as they are required to provide thread-safe functionality within libs. IMHO, it should be setup as follows: 1) libpthread.so has routines _pthread_* and references as pthread_* (I think they should be strong, but others think weak ;-) - suppose to be funny, not offensive). 2) libc.so accesses those (_pthread_*) functions and has weak symbols for the ones it use to work without libpthread.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:22 UTC