Re: pthreads

[William Ahern <william@...>]

On Thu, Aug 03, 2017 at 11:48:06AM -0400, Tom Callaway wrote:
> Hi Lua folks,
> 
> Recently, a bug came in for Fedora 26 saying that cgit was throwing
> error messages, specifically:
> 
> /var/www/cgi-bin/cgit: Relink `/lib64/liblua-5.3.so' with
> `/lib64/libpthread.so.0' for IFUNC symbol `system'
> 
> Now, it's worth pointing out that cgit wasn't actually failing at all,
> it was just being noisy in the logs. That said, it seemed like an easy
> fix, but in my experience, those are often the most controversial. :)
> 
> I've attached a patch which changes configure.ac to check for pthread
> support, using the ax_pthread.m4 from autoconf-archive. With this patch
> applied to lua-5.3.4, pthreads are detected, cflags and ldflags are set
> correctly, and cgit stops throwing this noise.
> 
> If there is a more preferred way to handle use of pthreads here, please
> let me know, as I do not want Fedora to diverge from lua upstream.

I found it really odd that -lpthread would need to be linked in for Lua's
use of system. It seems this might be a glibc regression introduced in 2.25.
See

  http://lists.openembedded.org/pipermail/openembedded-core/2017-January/130983.html
  http://lists.openembedded.org/pipermail/openembedded-core/2017-January/131119.html

Does cgit link against -lpthread, directly or indirectly (via another
library)? I wonder if this could be fixed by simply reordering the link
order, making sure -llua is specified before -lcurl, -lssl or w'ever
is bringing in pthreads.

I don't have a Fedora system to test on at the moment. But if you begin
building liblua-5.3.so with -lpthread, there's probably no going back unless
you want to risk breaking other people who accidentally end up relying on
liblua linking in pthreads--because they forget to link in pthreads, or
maybe because some library autodetects pthreads at runtime and changes
behavior, or because -lpthread overrides and re-implements severl libc
functions (e.g. longjmp and system), and these different implementations
might have different behavior.

OTOH, the _interpreter_ probably should link with -lpthreads. glibc has too
many bugs when lazily loading and initializing pthreads via dlopen. Both the
Perl and Python interpreters link in pthreads.