[PATCH] fix boringssl build
Hello, BoringSSL builds are broken https://travis-ci.com/github/haproxy/haproxy/jobs/351670996 I attached the fix. Cheers, Ilya Shipitcin From 39527ba53557aaf8a031401f00b6b217bec2935e Mon Sep 17 00:00:00 2001 From: Ilya Shipitsin Date: Sat, 20 Jun 2020 23:38:37 +0500 Subject: [PATCH] BUILD: fix ssl_sample.c when building against BoringSSL BoringSSL does not have X509_get_X509_PUBKEY let our emulation level define that for BoringSSL as well Build log: src/ssl_sample.o: In function `smp_fetch_ssl_x_key_alg': /home/travis/build/haproxy/haproxy/src/ssl_sample.c:592: undefined reference to `X509_get_X509_PUBKEY' clang-7: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:860: recipe for target 'haproxy' failed make: *** [haproxy] Error 1 travis-ci: https://travis-ci.com/github/haproxy/haproxy/jobs/351670996 --- include/haproxy/openssl-compat.h | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/include/haproxy/openssl-compat.h b/include/haproxy/openssl-compat.h index 34fe6cb76..acdc9c5bc 100644 --- a/include/haproxy/openssl-compat.h +++ b/include/haproxy/openssl-compat.h @@ -81,6 +81,9 @@ static inline void X509_ALGOR_get0(ASN1_OBJECT **paobj, int *pptype, const void #endif // OpenSSL < 0.9.8 +#if (((HA_OPENSSL_VERSION_NUMBER < 0x100fL) || defined(OPENSSL_IS_BORINGSSL)) && !defined(X509_get_X509_PUBKEY)) +#define X509_get_X509_PUBKEY(x) ((x)->cert_info->key) +#endif #if (HA_OPENSSL_VERSION_NUMBER < 0x100fL) /* Functions introduced in OpenSSL 1.0.0 */ @@ -98,10 +101,6 @@ static inline int X509_PUBKEY_get0_param(ASN1_OBJECT **ppkalg, const unsigned ch return 1; } -#ifndef X509_get_X509_PUBKEY -#define X509_get_X509_PUBKEY(x) ((x)->cert_info->key -#endif - #endif #if (HA_OPENSSL_VERSION_NUMBER < 0x1000100fL) -- 2.26.2
Re: [PATCH] BUG/MEDIUM: sink: fix crash when null sink is used in __do_send_log
Hello, On 6/19/20 3:22 PM, Willy Tarreau wrote: Hi Daniel, ... Thanks for the fix and the detailed report, that's very useful! However the problem is somewhere else, and I suspect is slightly harder to solve. It's normally not possible to have a null sink on a log server if its type is a buffer, so we have an inconsistency somewhere that we must address. I suspected this to be the case but could not really trace the root of the issue and chose the path of least resistance :) I'm CCing Emeric so that he can have a look, and am keeping the rest intact below. If I can provide any more info please let me know. Thanks, -- Daniel
Re: compile issues on FreeBSD/i386
Hi Dmitry, On Sat, Jun 20, 2020 at 03:30:55PM +0300, Dmitry Sivachenko wrote: > Hello! > > I am trying to compile haproxy-2.2-dev10 on FreeBSD-12/i386 (i386 is > important here) with clang version 9.0.1. > > I get the following linker error: > > LD haproxy > ld: error: undefined symbol: __atomic_fetch_add_8 > >>> referenced by backend.c > >>> src/backend.o:(assign_server) > >>> referenced by backend.c > >>> src/backend.o:(assign_server) > >>> referenced by backend.c > >>> src/backend.o:(assign_server_and_queue) > >>> referenced by backend.c > >>> src/backend.o:(assign_server_and_queue) > >>> referenced by backend.c > >>> src/backend.o:(assign_server_and_queue) > >>> referenced by backend.c > >>> src/backend.o:(assign_server_and_queue) > >>> referenced by backend.c > >>> src/backend.o:(connect_server) > >>> referenced by backend.c > >>> src/backend.o:(connect_server) > >>> referenced by backend.c > >>> src/backend.o:(connect_server) > >>> referenced by backend.c > >>> src/backend.o:(srv_redispatch_connect) > >>> referenced 233 more times > > ld: error: undefined symbol: __atomic_store_8 > > For some time we apply the following patch to build on FreeBSD/i386: > > --- include/common/hathreads.h.orig 2018-02-17 18:17:22.21940 + > +++ include/common/hathreads.h 2018-02-17 18:18:44.598422000 + > @@ -104,7 +104,7 @@ extern THREAD_LOCAL unsigned long tid_bit; /* The bit > /* TODO: thread: For now, we rely on GCC builtins but it could be a good > idea to > * have a header file regrouping all functions dealing with threads. */ > > -#if defined(__GNUC__) && (__GNUC__ < 4 || __GNUC__ == 4 && __GNUC_MINOR__ < > 7) && !defined(__clang__) > +#if (defined(__GNUC__) && (__GNUC__ < 4 || __GNUC__ == 4 && __GNUC_MINOR__ < > 7) && !defined(__clang__)) || (defined(__clang__) && defined(__i386__)) > /* gcc < 4.7 */ > > #define HA_ATOMIC_ADD(val, i)__sync_add_and_fetch(val, i) > > (it is from older -dev but still applies to include/haproxy/atomic.h and > fixes the build). > > If this patch is correct for i386, may be we include it to haproxy sources? The problem seems to be that clang assumes that the atomic access may be done unaligned. Fixing most of it is pretty straight forward, it mostly involves adding __attribute__((aligned(64))) on all the relevant structure members. However, no amount of cajoling helps for trace.c, as long as we use ev_ptr, it always assumes it may be unaligned. Even more funny, while HA_ATOMIC_STORE(>report_events, 0); will work if report_events is flagged as 64bits-aligned, HA_ATOMIC_STORE(ev_ptr == >report_events ? >report_events : >report_events, 0) will make clang unhappy. So I don't know how to handle that properly. Willy, I think Dmitry's solution of using the old builtins for clang/i386 might be the less intrusive way of fixing it. > PS: with that patch applied I get the following warning which can have sense: > > src/stick_table.c:3462:12: warning: result of comparison 'unsigned long' > > 4294967295 is always false [-Wtautological-type-limit-compare] > val > 0x) > ~~~ ^ ~~ > This one sounds mostly harmless, I guess whe should use a long long here, and strtoull(). Olivier
compile issues on FreeBSD/i386
Hello! I am trying to compile haproxy-2.2-dev10 on FreeBSD-12/i386 (i386 is important here) with clang version 9.0.1. I get the following linker error: LD haproxy ld: error: undefined symbol: __atomic_fetch_add_8 >>> referenced by backend.c >>> src/backend.o:(assign_server) >>> referenced by backend.c >>> src/backend.o:(assign_server) >>> referenced by backend.c >>> src/backend.o:(assign_server_and_queue) >>> referenced by backend.c >>> src/backend.o:(assign_server_and_queue) >>> referenced by backend.c >>> src/backend.o:(assign_server_and_queue) >>> referenced by backend.c >>> src/backend.o:(assign_server_and_queue) >>> referenced by backend.c >>> src/backend.o:(connect_server) >>> referenced by backend.c >>> src/backend.o:(connect_server) >>> referenced by backend.c >>> src/backend.o:(connect_server) >>> referenced by backend.c >>> src/backend.o:(srv_redispatch_connect) >>> referenced 233 more times ld: error: undefined symbol: __atomic_store_8 For some time we apply the following patch to build on FreeBSD/i386: --- include/common/hathreads.h.orig 2018-02-17 18:17:22.21940 + +++ include/common/hathreads.h 2018-02-17 18:18:44.598422000 + @@ -104,7 +104,7 @@ extern THREAD_LOCAL unsigned long tid_bit; /* The bit /* TODO: thread: For now, we rely on GCC builtins but it could be a good idea to * have a header file regrouping all functions dealing with threads. */ -#if defined(__GNUC__) && (__GNUC__ < 4 || __GNUC__ == 4 && __GNUC_MINOR__ < 7) && !defined(__clang__) +#if (defined(__GNUC__) && (__GNUC__ < 4 || __GNUC__ == 4 && __GNUC_MINOR__ < 7) && !defined(__clang__)) || (defined(__clang__) && defined(__i386__)) /* gcc < 4.7 */ #define HA_ATOMIC_ADD(val, i)__sync_add_and_fetch(val, i) (it is from older -dev but still applies to include/haproxy/atomic.h and fixes the build). If this patch is correct for i386, may be we include it to haproxy sources? PS: with that patch applied I get the following warning which can have sense: src/stick_table.c:3462:12: warning: result of comparison 'unsigned long' > 4294967295 is always false [-Wtautological-type-limit-compare] val > 0x) ~~~ ^ ~~ Thanks.
