Replace ancient m4/acx_pthread.m4 with m4/ax_pthread.m4 #1333
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a notional PR illustrating an issue we're having with Mosh on debian-sid; the root cause seems to lie with protobuf (though there are at least two bugs/changes elsewhere in the build chain that also contribute).
Protobuf uses the very old, obsoleted-in-2009
ACX_PTHREAD
macro to detect pthread libraries and set variables appropriately. On Debian Sid (and probably nearly any modern Linux distro),pkg-config --libs protobuf
returns-lprotobuf -pthread -lpthread
. Usage of-lpthread
has been deprecated for a long, long time, but protobuf has been getting away with it until now. Something has recently changed in sid's build toolchain or binutils or glibc so that the oddly-placed-lpthread
combined with Mosh's aggressive full-RELRO hardening causes a failure in symbol resolution elsewhere in Mosh, causingmosh-server
to segfault on an unresolved PLT entry for fork() at runtime. By adopting the newerAX_PTHREAD
macro from autoconf, we get a more-correct-lprotobuf -pthread
, and mosh is happier.See mobile-shell/mosh#727 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817929 for much more discussion on the issue.
I have no idea what the best path for protobuf's maintainers to fix this is, but this PR should illustrate the problem nicely.