On Fri, Aug 19, 2016 at 07:53:20PM +0200, Thomas Petazzoni wrote:
Hello,
[Adding Rich in Cc.]
On Fri, 19 Aug 2016 19:34:43 +0200, Waldemar Brodkorb wrote:
Do we
have a list of the pthread functions that libc.so/libc.a is
supposed to provide? See the mail I just send about the axel/libintl
issue where libintl also uses pthread_rwlock_*() without being linked
with libpthread.so.
I discussed the issues with Rich Felker and he is suggesting _not_
to do some wacky weak/strong handling of these symbols to provide
some hackish way for applications to save some space.
We should just link with -lpthread if any pthread_* function is in
use to avoid any surprises when actually running the application.
So please add explicit -lpthread for these static linking failures
and add in libpthread.a functions. It might be just by accident that
libc.so provides these function dummies for external uses and may be
we should fix this instead.
I'm sorry but I disagree with Rich's proposal here. Lots of libraries
rely on this behavior, and we will not be able to upstream the change
that consists in linking with -lpthread, because it means a performance
degradation when those libraries are used in mono-threaded applications.
It is *not* about saving some space like Rich said. It is about making
the mutex lock/unlock operations no-ops when they are not needed.
So I'm sorry, but uClibc should implement this behavior, or you will
have dozens of upstream projects to convince :-/
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
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.
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.
Rich