19 Aug
2016
19 Aug
'16
8:33 p.m.
Hi Thomas,
Thomas Petazzoni wrote,
Hello,
On Fri, 19 Aug 2016 21:46:44 +0200, Waldemar Brodkorb wrote:
The problem here is, we try to support static linking, which isn't
enabled for Buildroot GNU libc toolchains. So you do not see the
problems we are facing with uClibc-ng now.
If you really do not want to diverge from GNU libc behaviour, we can
just keep uClibc-ng as is, but you still need to add -lpthread in
case of static linking. This would be even required when using GNU
libc for static linking, which is technically possible and supported
by upstream. (with any known limitations regarding
pthread_cancel+libgcc_s.so.1 and nss_* functions)
I am not entirely sure, what is the best way to do.
But I am willing to help getting these pthread bugfixes into
upstream projects, if we go this way.
Or we make a new option: UCLIBC_COMBINED_LIBC which can be enabled
to mimic musl behaviour and adds librt/libm/libpthread into a single
libc :)
If libxml2 isn't supporting static linking, we have one less problem
to solve ;)
best regards
Waldemar
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.