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