On Wed, Jul 18, 2007, Jeff Johnson wrote: > [...] > If I read correctly, the conservative/portable approach is -lpthread in > executable so that external libraries linked with -lpthread function > correctly. That kinda forces "mandatory" -lpthread for rpm when > external libraries may (or may not) have -lpthread.
This is for what pkg-config(1) or a foo-config(1) of the third-library is for: that RPM doesn't have to know this or _always_ try to link against pthreads. And for the same reason why created our rpm.pc, btw. But this pthread mess is a general problem, yes. > [...] > The path forward is adding per-object thread locks, the path backwards is > removing -lpthread, the status quo needs to change no matter what. I'm always a little bit surprised that people use POSIX pthread mutex even in non-multithreaded applications. Sure, can be done. But that it really should be 10 times faster than some other mutex approaches I'm sceptical about -- perhaps for one single OS, ok. What is the purpose of RPM locking its database operations? That no second RPM instance (either rpm(1) or an RPM API based application) trashes it while one RPM is already operating, right? At least for this one doesn't need POSIX pthread mutexes. Here an fcntl(3) based approach even within RPM itself should be both sufficient and fast enough... Or are you planning that RPM can be really internally run multi-threaded? Then the case is different, of course. Then you _have_ to use POSIX pthreads, of course. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org