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.
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."
best regards
Waldemar
_______________________________________________
devel mailing list
devel@uclibc-ng.org
http://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
