]> git.ipfire.org Git - thirdparty/squid.git/commit
gcc-8+ build error: undefined reference to __atomic_is_lock_free (#625)
authorEduard Bagdasaryan <eduard.bagdasaryan@measurement-factory.com>
Tue, 12 May 2020 14:50:10 +0000 (14:50 +0000)
committerAmos Jeffries <yadij@users.noreply.github.com>
Fri, 22 May 2020 10:42:29 +0000 (22:42 +1200)
commitd7e0116b4729dbe33f57a9cd1b5d8d12430ee7a5
treebdb830731c79f56baa5946177cafa95bfb87344a
parentf47b409df9c243a2a1dbdca573a92b78d1fc6480
gcc-8+ build error: undefined reference to __atomic_is_lock_free (#625)

Compilers warned about AC_SEARCH_LIBS(__atomic_load_8)-generated code.
Newer, stricter compilers (e.g., gcc-8), exit with an error, resulting
in AC_SEARCH_LIBS failure when determining whether libatomic is needed.

More at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907277#30

It is unclear whether autoconf will ever handle this case better. Let's
use a custom-made test for now. The current test refuses to build Squid
on platforms where a program using std::atomic<T>::is_lock_free() cannot
be successfully linked (either with or without libatomic) for a the
largest atomic T used by Squid (i.e. a 64 bit integer).

Linking with libatomic may be required for many reasons that we do not
fully understand, but we know that std::atomic<T>::is_lock_free() does
require linking with libatomic in some environments, even where T is an
inlineable atomic. That is why we use that as a test case.
configure.ac