[uclibc-ng-devel] pthread_mutex_*() functions, dynamic vs. static linking

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Fri Aug 19 19:53:20 CEST 2016


[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 :-/

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering

More information about the devel mailing list