Hi Thomas, Thomas Petazzoni wrote, > 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.
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 _______________________________________________ devel mailing list devel@uclibc-ng.org http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
