Project

General

Profile

Bug #2884

lighttpd-1.4.49 fails to link against memcached without posix threads (-pthread) flag

Added by Zlogene 26 days ago. Updated 17 days ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
Category:
build_autotools
Target version:
Start date:
2018-04-29
Due date:
% Done:

0%

Estimated time:
Missing in 1.5.x:

Description

Hi, I am maintaining your package in the gentoo repository. During the latest bump I had noticed that lighty failed to configure if memcached was enabled as an option. Short research gave the answer, the build system told about undefined reference to the posix threads. So I had to force its application. to me it looks like the regression, the previous versions works fine with LDFLAGS from a user env.

Gentoo workaround looks like this:

https://gitweb.gentoo.org/repo/gentoo.git/tree/www-servers/lighttpd/lighttpd-1.4.49.ebuild#n116

Thanks for looking into it~

History

#1

Updated by gstrauss 26 days ago

Thanks for picking this up in Gentoo.

I started looking through the Gentoo ebuild files (not my area of expertise) for lighttpd.

Did this break in Gentoo between 1.4.45 -> 1.4.49 or between 1.4.47 -> 1.4.49? I ask because this is not broken in my development build, but I also don't have a build environment for every distro. Does Gentoo use autotools to build lighttpd? Or CMake? or scons?

Asides:
  • please use https links to *.lighttpd.net, e.g. https://download.lighttpd.net/
  • lighttpd works when linked with libressl instead of openssl, using the openssl compatibility layer in libressl.
  • use mmap is safe in lighttpd since 1.4.40, so no need for that warning in pkg_setup()
  • there are numerous additional modules in lighttpd since 1.4.45, and so remove_non_essential() should probably be updated. Also, it probably should not delete mod_compress, and then conditionally delete mod_compress if use_compress is not set. Another thing, if mod_fastcgi is part of the minimal set, the mod_proxy and mod_scgi probably should be part of that set, too, and should not be removed.
#2

Updated by gstrauss 26 days ago

  • Category set to build_autotools
#3

Updated by gstrauss 26 days ago

the build system told about undefined reference to the posix threads.

Would you attach some log snippets? Which modules failed to build? Anything besides mod_cml and mod_trigger_b4_dl?

#4

Updated by Zlogene 26 days ago

gstrauss wrote:

the build system told about undefined reference to the posix threads.

Would you attach some log snippets? Which modules failed to build? Anything besides mod_cml and mod_trigger_b4_dl?

configure:17204: checking for memcached
configure:17215: result: yes
configure:17223: checking for memcached in -lmemcached
configure:17248: x86_64-pc-linux-gnu-gcc -o conftest -O2 -pipe  -D_REENTRANT  -Wl,-O1 -Wl,--as-needed conftest.c -lmemcached   >&5
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lmemcached (undefined reference to `pthread_once')

but I have to admit that the bug is quite difficult to find, I am not sure what causes it, but to clarify I am using totally clear env w/o any additional packages installed it is the first version where I faced this behaviour

#5

Updated by Zlogene 26 days ago

gstrauss wrote:

Thanks for picking this up in Gentoo.

I started looking through the Gentoo ebuild files (not my area of expertise) for lighttpd.

Did this break in Gentoo between 1.4.45 -> 1.4.49 or between 1.4.47 -> 1.4.49? I ask because this is not broken in my development build, but I also don't have a build environment for every distro. Does Gentoo use autotools to build lighttpd? Or CMake? or scons?

Asides:
  • please use https links to *.lighttpd.net, e.g. https://download.lighttpd.net/
  • lighttpd works when linked with libressl instead of openssl, using the openssl compatibility layer in libressl.
  • use mmap is safe in lighttpd since 1.4.40, so no need for that warning in pkg_setup()
  • there are numerous additional modules in lighttpd since 1.4.45, and so remove_non_essential() should probably be updated. Also, it probably should not delete mod_compress, and then conditionally delete mod_compress if use_compress is not set. Another thing, if mod_fastcgi is part of the minimal set, the mod_proxy and mod_scgi probably should be part of that set, too, and should not be removed.

Thaks for the useful feedback! I have already updated our packages using https, will aslo handle the rest soon (I took the maintainership only a week ago, there is still some mess I want to clean up).
As for libssl, does your comment mean that I have to switch and pull only libressl as a dependency, and never try openssl one?

#6

Updated by stbuehler 26 days ago

Could you perhaps locate the libmemcached.so and check the ldd output?

On Debian it looks like this:

$ ldd /usr/lib/x86_64-linux-gnu/libmemcached.so
    linux-vdso.so.1 (0x00007ffe1add9000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1efe53d000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1efe339000)
    libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f1efe11e000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1efdd99000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1efda06000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1efd64c000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1efd434000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f1efe98c000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f1efd21d000)

And it indeed needs some pthread symbols:

$ nm -D /usr/lib/x86_64-linux-gnu/libmemcached.so | grep pthread
                 U pthread_mutex_lock
                 U pthread_mutex_unlock
                 U pthread_once

And a local configure --with-memcached looks like this:

configure:17238: checking for memcached in -lmemcached
configure:17263: gcc -o conftest -g -O2  -D_REENTRANT   conftest.c -lmemcached   >&5
configure:17263: $? = 0
configure:17272: result: yes

So if your libmemcached.so uses pthread_* symbols but doesn't link libpthread.so I'd say your libmemcached is buggy.

As we don't use threads in lighttpd there is no good reason for us to include -pthread in the flags.

#7

Updated by gstrauss 17 days ago

  • Status changed from New to Invalid

As for libssl, does your comment mean that I have to switch and pull only libressl as a dependency, and never try openssl one?

Of course not. lighttpd mod_openssl works with either openssl, or with libressl using the openssl compatibility layer in libressl.

@Zlogene have you had a chance to check with Gentoo libmemcached maintainer to see why libmemcached is not being built and linked with pthreads?

FYI: lighttpd 1.4.46 stopped linking openssl with the core executable, and instead moved TLS support to a separate module, mod_openssl. Since the openssl libraries link against pthreads, the lighttpd executable was always loading libpthread in lighttpd 1.4.45 and earlier, which libmemcached also required, but when lighttpd 1.4.46 stopped doing so, libmemcached in Gentoo broke because libmemcached in Gentoo is missing a dependency on pthreads.

Therefore, I am going to mark this ticket "Invalid", since it is not a bug in lighttpd, but feel free to continue asking questions here or in the forums, or on IRC freenode #lighttpd.

Also available in: Atom