On Thu, May 09, 2019 at 08:59:44PM +0000, Chris Packham wrote: > >> haproxy-1.9.7/src/fd.c:267: undefined reference to `__ha_cas_dw' (...) > >> collect2: error: ld returned 1 exit status > >> Makefile:994: recipe for target 'haproxy' failed > >> make: *** [haproxy] Error 1 > >> > >> Eyeballing the code I think it's because USE_THREAD is not defined and > >> __ha_cas_dw is only defined when USE_THREAD is defined (...)
> Here's the full make invocation (MUA wrapped unfortunately) > > make -j32 -l16 CC=arm-unknown-linux-gnueabihf-gcc > LD=arm-unknown-linux-gnueabihf-gcc > DESTDIR=output/armv7/haproxy/new/install PREFIX=/usr CFLAGS=-"O2 -g2 > -mtune=cortex-a9 -march=armv7-a -mabi=aapcs-linux > --sysroot=output/armv7/haproxy/staging > LDFLAGS=--sysroot=output/armv7/haproxy/staging USE_OPENSSL=1 > SSL_INC=output/armv7/haproxy/staging/usr/include > SSL_LIB=output/armv7/haproxy/staging/usr/lib TARGET=linux26 Oh you're absolutely right. I build my arm versions with threads by default and I didn't notice this one. I can obviously reproduce it as well. The problem doesn't happen on x86_64 because it has the macro HA_CAS_IS_8B defined and it can fall back to the regular CAS macro which is implemented in this case. We should have a higher level HA_CAS_DW function that supports absence of threads and use this one instead. I'll double-check with Olivier. Thanks, Willy
