Hi Thomas, Thomas Petazzoni wrote, > Hello, > > On Fri, 19 Aug 2016 14:03:45 -0400, Rich Felker wrote: > > > If they want to keep taking advantage of the nop-out hack for dynamic > > linking glibc, a suitable solution would be a configure check > > something like: > > > > checking whether -larchive needs -lpthread... yes > > That's a whole lot of work in potentially numerous upstream packages :-/ > > Also, there's still the odd thing that with uClibc, linking an > application using pthread_mutex_lock/unlock with just libc works fine > when dynamic linking, but not when static linking. > > If the decision is indeed that there is no fallback implementation in > libc, then there shouldn't be any fallback implementation, regardless > of whether we're static linking or not. > > > However, I'm not sure glibc will even be keeping this behavior > > long-term, as it's silent-error-prone. Some programmers have been very > > unpleasantly surprised to find out that the dummy lock functions in > > glibc's libc.{so,a} don't even enforce any exclusion. I believe this > > was visible in trylock succeeding on an already-locked mutex where it > > should have failed. I just did a quick search to see if I could find > > this discussion on the bug tracker but I didn't find it; it might be > > on the mailing list or somewhere else, or just buried somewhere that's > > hard to search. > > > > Note that because there exist process-shared mutexes, the dummy > > implementation is actually unsafe. An application might omit linking > > -lpthread because it sees that it links fine without it, but then mmap > > some shared memory and use pthread_mutex_lock for inter-process > > synchronization. Very bad silent breakage then happens. > > Indeed. > > > IMO the right fix is not to link a dummy implementation but instead to > > have the real implementation provide fast-paths for (!multi_threaded > > && !process_shared) cases. > > OK, makes sense. > > Waldemar, how do you see things moving forward in uClibc? Removing the > fallback implementation entirely?
Removing the visibility of the pthread_mutex_* dummies would be the best, so that dynamic linking is failing, when -lpthread is missing. Isn't it like with librt? Usually you use -lrt when using any advanced realtime functions from the C library. And any tutorial you find with your favourite internet search engine mentions to use -lpthread or -pthread when linking an application which uses pthread.h. So who is actually to blame for this situation that application programmers try to use pthread.h without linking libpthread? :) http://linux.die.net/man/7/pthreads "On Linux, programs that use the Pthreads API should be compiled using cc -pthread." best regards Waldemar _______________________________________________ devel mailing list devel@uclibc-ng.org http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel