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.


Reply via email to