Hello, On Fri, 19 Aug 2016 21:46:44 +0200, Waldemar Brodkorb wrote:
> 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." The key part here is *programs*. Here, the situation is about a library that uses some aspects of the pthread API without knowing if the program is multi-threaded or not. I could find some old references about libxml2 (which uses pthread_* symbols but doesn't link with libpthread): """ > I've since chatted with Daniel (the upstream maintainer of > libxml2). He's in agreement with me that linking libxml2 with pthreads > is an unacceptable performance hit. I also have the issue that I do not > want to link my application with pthreads, and I don't think I should > have to. """ See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=142754. But there is some other relevant discussion at https://bugzilla.gnome.org/show_bug.cgi?id=704904. This is really my main concern: how many packages will we have to patch? Will those patches make their way upstream? This is especially true if we diverge from glibc's behavior, which (for good or bad) is generally considered by most developers as the "right" behavior. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com _______________________________________________ devel mailing list devel@uclibc-ng.org http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
