Trying to compile current master on OS-X, and get:
gcc -Iinclude -Iebtree -Wall -O0 -g -fno-strict-aliasing
-Wdeclaration-after-statement -fwrapv -fno-strict-overflow
-Wno-address-of-packed-member -Wno-null-dereference
-Wno-unused-label -DTPROXY -DUSE_ZLIB -DENABLE_POLL
-DENABLE_KQUEUE -DUSE_OPENSSL
-I/Users/phemmer/git/haproxy/openssl-1.1.0h/include -DUSE_LUA
-I/Users/phemmer/git/haproxy/lua-5.3.4/src
-I/Users/phemmer/git/haproxy/lua-5.3.4/src -DUSE_PCRE
-I/opt/local/include -DCONFIG_HAPROXY_VERSION=\"1.9-dev0-ba86c6-462\"
-DCONFIG_HAPROXY_DATE=\"2018/06/22\" \
-DBUILD_TARGET='"osx"' \
-DBUILD_ARCH='""' \
-DBUILD_CPU='"generic"' \
-DBUILD_CC='"gcc"' \
-DBUILD_CFLAGS='"-O0 -g -fno-strict-aliasing
-Wdeclaration-after-statement -fwrapv -fno-strict-overflow
-Wno-address-of-packed-member -Wno-null-dereference -Wno-unused-label"' \
-DBUILD_OPTIONS='"USE_ZLIB=1 USE_OPENSSL=1
USE_LUA=1 USE_PCRE=1"' \
-c -o src/haproxy.o src/haproxy.c
clang: warning: argument unused during compilation:
'-fno-strict-overflow' [-Wunused-command-line-argument]
src/haproxy.c:2476:16: error: cannot take the address of an
rvalue of type 'unsigned long'
HA_ATOMIC_AND(&all_threads_mask, ~tid_bit);
^~~~~~~~~~~~~~~~~
include/common/hathreads.h:41:42: note: expanded from macro
'HA_ATOMIC_AND'
#define HA_ATOMIC_AND(val, flags) ({*(val) &= (flags);})
^~~
1 error generated.
make: *** [src/haproxy.o] Error 1
Built with: Apple LLVM version 9.0.0 (clang-900.0.39.2)
This broke in change ba86c6c:
commit ba86c6c25bf252e44589ae2b4d51a67c4f47d244 (HEAD -> master,
origin/master, origin/HEAD)
Author: Christopher Faulet <cfau...@haproxy.com>
Date: Thu Jun 21 09:57:39 2018 +0200
MINOR: threads: Be sure to remove threads from all_threads_mask on exit
When HAProxy is started with several threads, Each running thread
holds a bit in
the bitfiled all_threads_mask. This bitfield is used here and there
to check
which threads are registered to take part in a specific processing.
So when a
thread exits, it seems normal to remove it from all_threads_mask.
No direct impact could be identified with this right now but it would
be better to backport it to 1.8 as a preventive measure to avoid complex
situations like the one in previous bug.
-Patrick
