On Fri, Aug 19, 2016 at 09:46:44PM +0200, Waldemar Brodkorb wrote:
> 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.
This breakage (and the need for upstream application fixes) can be
avoided by moving the lock functions into libc.{a,so}. IIRC for glibc
that's a bit messy because of symbol versioning. Not sure how hard it
would be for uclibc[-ng].
> 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."
I agree but I think Thomas wants to avoid the need to patch/fix all
the broken application build systems out there.
Rich
_______________________________________________
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
