Re: Building HAProxy 1.8 fails on Solaris
Actually, we can successfully compile the latest 1.7 on the same Solaris setup, without USE_PTHREAD_PSHARED. You're right about the patch, though; it seems unnecessary with that flag. Thanks! On Saturday, 21 July 2018, 10:07:41 am AEST, Olivier Houchard wrote: My patch won't be applied, so it'll behave the exact same way it used to. Reading the 1.6 code, the calls to __sync_lock* were already there, so it probably did not compile on Solaris with a gcc older than 4.1, unless USE_PTHREAD_PSHARED was defined. Regards, Olivier
Re: Building HAProxy 1.8 fails on Solaris
Hi, On Sat, Jul 21, 2018 at 12:51:53AM +0200, Lukas Tribus wrote: > Hello, > > On Fri, 20 Jul 2018 at 15:58, Olivier Houchard wrote: > > > > Hi LuKas, > > > > On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote: > > > Hello Oliver, > > > > > > On Fri, 20 Jul 2018 at 11:55, Olivier Houchard > > > wrote: > > > > > > > > Hi, > > > > > > > > On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote: > > > > > So...is there a way to adapt this patch so it won't cause random SSL > > > errors and is suitable to apply to the trunk? We don't really want to run > > > a > > > customised build in production... > > > > > > > > You don't need the patch, just using USE_PTHREAD_PSHARED=yes should be > > > enough. > > > > > > I don't really understand, are you saying that the spinlock introduced > > > in cd1a526a doesn't work properly (as in: causes random SSL errors)? How > > > does this work on FreeBSD and OpenBSD? This sounds like a supported > > > configuration on a supported OS causes random SSL errrors when in > > > multiprocess mode, but I imagine I got something wrong here. > > > > > > Please help me understand this issue. > > > > > > > No, it works fine, but if you compile without USE_THREADS, the HA_ATOMIC* > > macroes I used in my patch are in fact not atomic at all, so that may cause > > random and unpredictable failures if the SSL cache code use them. > > Ok, I guess my question is, how can we improve this so that SSL cache > doesn't unpredictably fail? > Threading is a huge feature, but behaving unpredictably when threading > is disabled (or unsupported on the specific OS) is bad. > > Can't the code handle the SSL cache like it did before threading was > introduced, when threading is disabled? > > My patch won't be applied, so it'll behave the exact same way it used to. Reading the 1.6 code, the calls to __sync_lock* were already there, so it probably did not compile on Solaris with a gcc older than 4.1, unless USE_PTHREAD_PSHARED was defined. Regards, Olivier
Re: Building HAProxy 1.8 fails on Solaris
Hello, On Fri, 20 Jul 2018 at 15:58, Olivier Houchard wrote: > > Hi LuKas, > > On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote: > > Hello Oliver, > > > > On Fri, 20 Jul 2018 at 11:55, Olivier Houchard > > wrote: > > > > > > Hi, > > > > > > On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote: > > > > So...is there a way to adapt this patch so it won't cause random SSL > > errors and is suitable to apply to the trunk? We don't really want to run a > > customised build in production... > > > > > > You don't need the patch, just using USE_PTHREAD_PSHARED=yes should be > > enough. > > > > I don't really understand, are you saying that the spinlock introduced > > in cd1a526a doesn't work properly (as in: causes random SSL errors)? How > > does this work on FreeBSD and OpenBSD? This sounds like a supported > > configuration on a supported OS causes random SSL errrors when in > > multiprocess mode, but I imagine I got something wrong here. > > > > Please help me understand this issue. > > > > No, it works fine, but if you compile without USE_THREADS, the HA_ATOMIC* > macroes I used in my patch are in fact not atomic at all, so that may cause > random and unpredictable failures if the SSL cache code use them. Ok, I guess my question is, how can we improve this so that SSL cache doesn't unpredictably fail? Threading is a huge feature, but behaving unpredictably when threading is disabled (or unsupported on the specific OS) is bad. Can't the code handle the SSL cache like it did before threading was introduced, when threading is disabled? Thanks, Lukas
Re: Building HAProxy 1.8 fails on Solaris
Hi LuKas, On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote: > Hello Oliver, > > On Fri, 20 Jul 2018 at 11:55, Olivier Houchard > wrote: > > > > Hi, > > > > On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote: > > > So...is there a way to adapt this patch so it won't cause random SSL > errors and is suitable to apply to the trunk? We don't really want to run a > customised build in production... > > > > You don't need the patch, just using USE_PTHREAD_PSHARED=yes should be > enough. > > I don't really understand, are you saying that the spinlock introduced > in cd1a526a doesn't work properly (as in: causes random SSL errors)? How > does this work on FreeBSD and OpenBSD? This sounds like a supported > configuration on a supported OS causes random SSL errrors when in > multiprocess mode, but I imagine I got something wrong here. > > Please help me understand this issue. > No, it works fine, but if you compile without USE_THREADS, the HA_ATOMIC* macroes I used in my patch are in fact not atomic at all, so that may cause random and unpredictable failures if the SSL cache code use them. Regards, Olivier
Re: Building HAProxy 1.8 fails on Solaris
Hello Oliver, On Fri, 20 Jul 2018 at 11:55, Olivier Houchard wrote: > > Hi, > > On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote: > > So...is there a way to adapt this patch so it won't cause random SSL errors and is suitable to apply to the trunk? We don't really want to run a customised build in production... > > You don't need the patch, just using USE_PTHREAD_PSHARED=yes should be enough. I don't really understand, are you saying that the spinlock introduced in cd1a526a doesn't work properly (as in: causes random SSL errors)? How does this work on FreeBSD and OpenBSD? This sounds like a supported configuration on a supported OS causes random SSL errrors when in multiprocess mode, but I imagine I got something wrong here. Please help me understand this issue. Thanks, Lukas
Re: Building HAProxy 1.8 fails on Solaris
Hi, On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote: > So...is there a way to adapt this patch so it won't cause random SSL errors > and is suitable to apply to the trunk? We don't really want to run a > customised build in production... You don't need the patch, just using USE_PTHREAD_PSHARED=yes should be enough. Regards, Olivier > On Wednesday, 18 July 2018, 10:45:38 pm AEST, Olivier Houchard > wrote: > > Hi, > > On Wed, Jul 18, 2018 at 02:17:59AM +, Thrawn wrote: > > Mea culpa, I applied the patch incorrectly. After fixing that, I can > > successfully build with 'USE_THREAD=' but without 'USE_PTHREAD_PSHARED=yes' > > (although from what Olivier said, I probably shouldn't do that). On > > Wednesday, 18 July 2018, 12:10:57 pm AEST, Thrawn > > wrote: > > Yeah the patch may get you to experience random errors if you share a SSL > cache across multiple process, USE_PTHREAD_PSHARED=yes should build as well, > and should do the right thing. > > Regards, > > Olivier >
Re: Building HAProxy 1.8 fails on Solaris
So...is there a way to adapt this patch so it won't cause random SSL errors and is suitable to apply to the trunk? We don't really want to run a customised build in production... On Wednesday, 18 July 2018, 10:45:38 pm AEST, Olivier Houchard wrote: Hi, On Wed, Jul 18, 2018 at 02:17:59AM +, Thrawn wrote: > Mea culpa, I applied the patch incorrectly. After fixing that, I can > successfully build with 'USE_THREAD=' but without 'USE_PTHREAD_PSHARED=yes' > (although from what Olivier said, I probably shouldn't do that). On > Wednesday, 18 July 2018, 12:10:57 pm AEST, Thrawn > wrote: Yeah the patch may get you to experience random errors if you share a SSL cache across multiple process, USE_PTHREAD_PSHARED=yes should build as well, and should do the right thing. Regards, Olivier
Re: Building HAProxy 1.8 fails on Solaris
Hi, On Wed, Jul 18, 2018 at 02:17:59AM +, Thrawn wrote: > Mea culpa, I applied the patch incorrectly. After fixing that, I can > successfully build with 'USE_THREAD=' but without 'USE_PTHREAD_PSHARED=yes' > (although from what Olivier said, I probably shouldn't do that). On > Wednesday, 18 July 2018, 12:10:57 pm AEST, Thrawn > wrote: Yeah the patch may get you to experience random errors if you share a SSL cache across multiple process, USE_PTHREAD_PSHARED=yes should build as well, and should do the right thing. Regards, Olivier
Re: Building HAProxy 1.8 fails on Solaris
Mea culpa, I applied the patch incorrectly. After fixing that, I can successfully build with 'USE_THREAD=' but without 'USE_PTHREAD_PSHARED=yes' (although from what Olivier said, I probably shouldn't do that). On Wednesday, 18 July 2018, 12:10:57 pm AEST, Thrawn wrote: We always clean before building. The shell script I use is currently: MAKE=/usr/sfw/bin/gmake$MAKE clean$MAKE USE_STATIC_PCRE=1 ARCH=native TARGET=solaris PCREDIR=../pcre USE_THREAD= USE_PTHREAD_PSHARED=yes And after applying the patch (and USE_PTHREAD_PSHARED=yes as you can see), that builds successfully :). Dropping 'USE_THREAD=' causes a fast failure complaining about '__sync_fetch_and_add' and '__sync_sub_and_fetch'. Dropping 'USE_PTHREAD_PSHARED=yes' results in an eventual failure: gcc -Iinclude -Iebtree -Wall -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-unused-label -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -DTPROXY -DCONFIG_HAP_CRYPT -DNEED_CRYPT_H -DUSE_GETADDRINFO -DENABLE_POLL -DUSE_PCRE -I../pcre/include -DCONFIG_HAPROXY_VERSION=\"1.8.12-8a200c7\" -DCONFIG_HAPROXY_DATE=\"2018/06/27\" -c -o src/cache.o src/cache.cIn file included from src/cache.c:31:include/proto/shctx.h: In function `cmpxchg':include/proto/shctx.h:140: error: invalid type argument of `unary *'include/proto/shctx.h:140: error: invalid type argument of `unary *'include/proto/shctx.h:140: warning: left-hand operand of comma expression has no effectgmake: *** [src/cache.o] Error 1 Thanks for the help :). Anything further that I should test, or should I just wait for some variety of this patch to land in 1.8.13? Regards ThrawnOn Wednesday, 18 July 2018, 1:33:12 am AEST, Olivier Houchard wrote: Hi again, On Tue, Jul 17, 2018 at 01:55:33PM +0200, Olivier Houchard wrote: > Hi Lukas, > > On Tue, Jul 17, 2018 at 01:08:39PM +0200, Lukas Tribus wrote: > > On Tue, 17 Jul 2018 at 01:09, Thrawn > > wrote: > > > > > > Ah, indeed, the GCC version provided on our server is 3.4.3. But the > > > readme on https://github.com/haproxy/haproxy says "GCC between 2.95 and > > > 4.8". Can the build be changed to continue supporting older GCC, or do > > > the docs need an update? > > > > Like I said earlier, "make clean" before compiling with different > > parameters, like USE_THREAD= > > > > Haproxy 1.8 is supposed to build fine with gcc 3 when disabling > > threading, but if you just compiled with threads enabled, you do need > > to "make clean": > > > > > > > I think your gcc is just too old. Those appeared around gcc 4.1 or so. > > > > With USE_THREAD= it is supposed to build fine. While threading will > > not work with gcc 3, we did not drop support for gcc3 altogether. > > > > > > Unfortunately it is not true. __sync_* was used in include/proto/shctx.h. > The attached patch uses the haproxy macroes instead, and so should get it > to compile again with older gcc. Thrawn, can you please test it ? > After talking with Will a bit, we realized this patch might not work if using a cache shared across multiple process. Can you just add USE_PTHREAD_PSHARED=yes on your command line, it should do the trick ? Thanks ! Olivier
Re: Building HAProxy 1.8 fails on Solaris
We always clean before building. The shell script I use is currently: MAKE=/usr/sfw/bin/gmake$MAKE clean$MAKE USE_STATIC_PCRE=1 ARCH=native TARGET=solaris PCREDIR=../pcre USE_THREAD= USE_PTHREAD_PSHARED=yes And after applying the patch (and USE_PTHREAD_PSHARED=yes as you can see), that builds successfully :). Dropping 'USE_THREAD=' causes a fast failure complaining about '__sync_fetch_and_add' and '__sync_sub_and_fetch'. Dropping 'USE_PTHREAD_PSHARED=yes' results in an eventual failure: gcc -Iinclude -Iebtree -Wall -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -Wno-unused-label -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -DTPROXY -DCONFIG_HAP_CRYPT -DNEED_CRYPT_H -DUSE_GETADDRINFO -DENABLE_POLL -DUSE_PCRE -I../pcre/include -DCONFIG_HAPROXY_VERSION=\"1.8.12-8a200c7\" -DCONFIG_HAPROXY_DATE=\"2018/06/27\" -c -o src/cache.o src/cache.cIn file included from src/cache.c:31:include/proto/shctx.h: In function `cmpxchg':include/proto/shctx.h:140: error: invalid type argument of `unary *'include/proto/shctx.h:140: error: invalid type argument of `unary *'include/proto/shctx.h:140: warning: left-hand operand of comma expression has no effectgmake: *** [src/cache.o] Error 1 Thanks for the help :). Anything further that I should test, or should I just wait for some variety of this patch to land in 1.8.13? Regards ThrawnOn Wednesday, 18 July 2018, 1:33:12 am AEST, Olivier Houchard wrote: Hi again, On Tue, Jul 17, 2018 at 01:55:33PM +0200, Olivier Houchard wrote: > Hi Lukas, > > On Tue, Jul 17, 2018 at 01:08:39PM +0200, Lukas Tribus wrote: > > On Tue, 17 Jul 2018 at 01:09, Thrawn > > wrote: > > > > > > Ah, indeed, the GCC version provided on our server is 3.4.3. But the > > > readme on https://github.com/haproxy/haproxy says "GCC between 2.95 and > > > 4.8". Can the build be changed to continue supporting older GCC, or do > > > the docs need an update? > > > > Like I said earlier, "make clean" before compiling with different > > parameters, like USE_THREAD= > > > > Haproxy 1.8 is supposed to build fine with gcc 3 when disabling > > threading, but if you just compiled with threads enabled, you do need > > to "make clean": > > > > > > > I think your gcc is just too old. Those appeared around gcc 4.1 or so. > > > > With USE_THREAD= it is supposed to build fine. While threading will > > not work with gcc 3, we did not drop support for gcc3 altogether. > > > > > > Unfortunately it is not true. __sync_* was used in include/proto/shctx.h. > The attached patch uses the haproxy macroes instead, and so should get it > to compile again with older gcc. Thrawn, can you please test it ? > After talking with Will a bit, we realized this patch might not work if using a cache shared across multiple process. Can you just add USE_PTHREAD_PSHARED=yes on your command line, it should do the trick ? Thanks ! Olivier
Re: Building HAProxy 1.8 fails on Solaris
Hi again, On Tue, Jul 17, 2018 at 01:55:33PM +0200, Olivier Houchard wrote: > Hi Lukas, > > On Tue, Jul 17, 2018 at 01:08:39PM +0200, Lukas Tribus wrote: > > On Tue, 17 Jul 2018 at 01:09, Thrawn > > wrote: > > > > > > Ah, indeed, the GCC version provided on our server is 3.4.3. But the > > > readme on https://github.com/haproxy/haproxy says "GCC between 2.95 and > > > 4.8". Can the build be changed to continue supporting older GCC, or do > > > the docs need an update? > > > > Like I said earlier, "make clean" before compiling with different > > parameters, like USE_THREAD= > > > > Haproxy 1.8 is supposed to build fine with gcc 3 when disabling > > threading, but if you just compiled with threads enabled, you do need > > to "make clean": > > > > > > > I think your gcc is just too old. Those appeared around gcc 4.1 or so. > > > > With USE_THREAD= it is supposed to build fine. While threading will > > not work with gcc 3, we did not drop support for gcc3 altogether. > > > > > > Unfortunately it is not true. __sync_* was used in include/proto/shctx.h. > The attached patch uses the haproxy macroes instead, and so should get it > to compile again with older gcc. Thrawn, can you please test it ? > After talking with Will a bit, we realized this patch might not work if using a cache shared across multiple process. Can you just add USE_PTHREAD_PSHARED=yes on your command line, it should do the trick ? Thanks ! Olivier
Re: Building HAProxy 1.8 fails on Solaris
Hi Lukas,
On Tue, Jul 17, 2018 at 01:08:39PM +0200, Lukas Tribus wrote:
> On Tue, 17 Jul 2018 at 01:09, Thrawn wrote:
> >
> > Ah, indeed, the GCC version provided on our server is 3.4.3. But the readme
> > on https://github.com/haproxy/haproxy says "GCC between 2.95 and 4.8". Can
> > the build be changed to continue supporting older GCC, or do the docs need
> > an update?
>
> Like I said earlier, "make clean" before compiling with different
> parameters, like USE_THREAD=
>
> Haproxy 1.8 is supposed to build fine with gcc 3 when disabling
> threading, but if you just compiled with threads enabled, you do need
> to "make clean":
>
>
> > I think your gcc is just too old. Those appeared around gcc 4.1 or so.
>
> With USE_THREAD= it is supposed to build fine. While threading will
> not work with gcc 3, we did not drop support for gcc3 altogether.
>
>
Unfortunately it is not true. __sync_* was used in include/proto/shctx.h.
The attached patch uses the haproxy macroes instead, and so should get it
to compile again with older gcc. Thrawn, can you please test it ?
Thanks !
Olivier
>From 91546285ceed74516f42a9e98fac14a5094133e0 Mon Sep 17 00:00:00 2001
From: Olivier Houchard
Date: Tue, 17 Jul 2018 13:52:19 +0200
Subject: [PATCH] MINOR: shctx: Use HA_ATOMIC_* instead of using the gcc
builtins.
When implementing atomic operations, use the HA_ATOMIC macroes provided by
hathreads.h, instead of using the (old) gcc builtins. That way it may uses
the newer builtins, or get it to compile with an old gcc that doesn't provide
any atomic builtins.
---
include/proto/shctx.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/proto/shctx.h b/include/proto/shctx.h
index 55cb2a77..4eed582b 100644
--- a/include/proto/shctx.h
+++ b/include/proto/shctx.h
@@ -132,17 +132,18 @@ static inline unsigned char atomic_dec(unsigned int *ptr)
#else /* if no x86_64 or i586 arch: use less optimized gcc >= 4.1 built-ins */
static inline unsigned int xchg(unsigned int *ptr, unsigned int x)
{
- return __sync_lock_test_and_set(ptr, x);
+ return HA_ATOMIC_XCHG(ptr, x);
}
static inline unsigned int cmpxchg(unsigned int *ptr, unsigned int old,
unsigned int new)
{
- return __sync_val_compare_and_swap(ptr, old, new);
+ HA_ATOMIC_CAS(ptr, , new);
+ return old;
}
static inline unsigned char atomic_dec(unsigned int *ptr)
{
- return __sync_sub_and_fetch(ptr, 1) ? 1 : 0;
+ return HA_ATOMIC_SUB(ptr, 1) ? 1 : 0;
}
#endif
--
2.14.3
Re: Building HAProxy 1.8 fails on Solaris
On Tue, 17 Jul 2018 at 01:09, Thrawn wrote: > > Ah, indeed, the GCC version provided on our server is 3.4.3. But the readme > on https://github.com/haproxy/haproxy says "GCC between 2.95 and 4.8". Can > the build be changed to continue supporting older GCC, or do the docs need an > update? Like I said earlier, "make clean" before compiling with different parameters, like USE_THREAD= Haproxy 1.8 is supposed to build fine with gcc 3 when disabling threading, but if you just compiled with threads enabled, you do need to "make clean": > I think your gcc is just too old. Those appeared around gcc 4.1 or so. With USE_THREAD= it is supposed to build fine. While threading will not work with gcc 3, we did not drop support for gcc3 altogether. cheers, Lukas
Re: Building HAProxy 1.8 fails on Solaris
Ah, indeed, the GCC version provided on our server is 3.4.3. But the readme on https://github.com/haproxy/haproxy says "GCC between 2.95 and 4.8". Can the build be changed to continue supporting older GCC, or do the docs need an update? Thanks for the quick help. On Monday, 16 July 2018, 8:58:40 pm AEST, Lukas Tribus wrote: Hello, On Mon, 16 Jul 2018 at 03:12, Thrawn wrote: > > Update: If I disable threading with > > USE_THREAD= > > then the build gets much further, but still fails eventually with: > > gcc -g -o haproxy src/ev_poll.o ebtree/ebtree.o ebtree/eb32sctree.o > ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o ebtree/ebsttree.o > ebtree/ebimtree.o ebtree/ebistree.o src/proto_http.o src/cfgparse.o > src/server.o src/stream.o src/flt_spoe.o src/stick_table.o src/stats.o > src/mux_h2.o src/checks.o src/haproxy.o src/log.o src/dns.o src/peers.o > src/standard.o src/sample.o src/cli.o src/stream_interface.o src/proto_tcp.o > src/backend.o src/proxy.o src/tcp_rules.o src/listener.o src/flt_http_comp.o > src/pattern.o src/cache.o src/filters.o src/vars.o src/acl.o src/payload.o > src/connection.o src/raw_sock.o src/proto_uxst.o src/flt_trace.o > src/session.o src/ev_select.o src/channel.o src/task.o src/queue.o > src/applet.o src/map.o src/frontend.o src/freq_ctr.o src/lb_fwlc.o > src/mux_pt.o src/auth.o src/fd.o src/hpack-dec.o src/memory.o src/lb_fwrr.o > src/lb_chash.o src/lb_fas.o src/hathreads.o src/chunk.o src/lb_map.o > src/xxhash.o src/regex.o src/shctx.o src/buffer.o src/action.o src/h1.o > src/compression.o src/pipe.o src/namespace.o src/sha1.o src/hpack-tbl.o > src/hpack-enc.o src/uri_auth.o src/time.o src/proto_udp.o src/arg.o > src/signal.o src/protocol.o src/lru.o src/hdr_idx.o src/hpack-huff.o > src/mailers.o src/h2.o src/base64.o src/hash.o -lnsl -lsocket -lcrypt > -L../pcre/lib -Wl,-Bstatic -lpcreposix -lpcre -Wl,-Bdynamic > Undefined first referenced > symbol in file > __sync_sub_and_fetch src/cache.o > __sync_val_compare_and_swap src/cache.o > __sync_lock_test_and_set src/cache.o > ld: fatal: symbol referencing errors. No output written to haproxy > collect2: ld returned 1 exit status > gmake: *** [haproxy] Error 1 Are you sure you did a "make clean" before building with USE_THREAD= ? Also please provide the output of "gcc --version". lukas On Monday, 16 July 2018, 11:12:34 pm AEST, Olivier Houchard wrote: Hi, I think your gcc is just too old. Those appeared around gcc 4.1 or so. Regards, Olivier
Re: Building HAProxy 1.8 fails on Solaris
Hi, On Mon, Jul 16, 2018 at 01:12:18AM +, Thrawn wrote: > Update: If I disable threading with > USE_THREAD= > then the build gets much further, but still fails eventually with: > gcc -g -o haproxy src/ev_poll.o ebtree/ebtree.o ebtree/eb32sctree.o > ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o ebtree/ebsttree.o > ebtree/ebimtree.o ebtree/ebistree.o src/proto_http.o src/cfgparse.o > src/server.o src/stream.o src/flt_spoe.o src/stick_table.o src/stats.o > src/mux_h2.o src/checks.o src/haproxy.o src/log.o src/dns.o src/peers.o > src/standard.o src/sample.o src/cli.o src/stream_interface.o src/proto_tcp.o > src/backend.o src/proxy.o src/tcp_rules.o src/listener.o src/flt_http_comp.o > src/pattern.o src/cache.o src/filters.o src/vars.o src/acl.o src/payload.o > src/connection.o src/raw_sock.o src/proto_uxst.o src/flt_trace.o > src/session.o src/ev_select.o src/channel.o src/task.o src/queue.o > src/applet.o src/map.o src/frontend.o src/freq_ctr.o src/lb_fwlc.o > src/mux_pt.o src/auth.o src/fd.o src/hpack-dec.o src/memory.o src/lb_fwrr.o > src/lb_chash.o src/lb_fas.o src/hathreads.o src/chunk.o src/lb_map.o > src/xxhash.o src/regex.o src/shctx.o src/buffer.o src/action.o src/h1.o > src/compression.o src/pipe.o src/namespace.o src/sha1.o src/hpack-tbl.o > src/hpack-enc.o src/uri_auth.o src/time.o src/proto_udp.o src/arg.o > src/signal.o src/protocol.o src/lru.o src/hdr_idx.o src/hpack-huff.o > src/mailers.o src/h2.o src/base64.o src/hash.o -lnsl -lsocket -lcrypt > -L../pcre/lib -Wl,-Bstatic -lpcreposix -lpcre -Wl,-Bdynamic Undefined > first referenced symbol in > file__sync_sub_and_fetch > src/cache.o__sync_val_compare_and_swap > src/cache.o__sync_lock_test_and_set src/cache.old: fatal: symbol > referencing errors. No output written to haproxycollect2: ld returned 1 exit > statusgmake: *** [haproxy] Error 1 I think your gcc is just too old. Those appeared around gcc 4.1 or so. Regards, Olivier
Re: Building HAProxy 1.8 fails on Solaris
Hello, On Mon, 16 Jul 2018 at 03:12, Thrawn wrote: > > Update: If I disable threading with > > USE_THREAD= > > then the build gets much further, but still fails eventually with: > > gcc -g -o haproxy src/ev_poll.o ebtree/ebtree.o ebtree/eb32sctree.o > ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o ebtree/ebsttree.o > ebtree/ebimtree.o ebtree/ebistree.o src/proto_http.o src/cfgparse.o > src/server.o src/stream.o src/flt_spoe.o src/stick_table.o src/stats.o > src/mux_h2.o src/checks.o src/haproxy.o src/log.o src/dns.o src/peers.o > src/standard.o src/sample.o src/cli.o src/stream_interface.o src/proto_tcp.o > src/backend.o src/proxy.o src/tcp_rules.o src/listener.o src/flt_http_comp.o > src/pattern.o src/cache.o src/filters.o src/vars.o src/acl.o src/payload.o > src/connection.o src/raw_sock.o src/proto_uxst.o src/flt_trace.o > src/session.o src/ev_select.o src/channel.o src/task.o src/queue.o > src/applet.o src/map.o src/frontend.o src/freq_ctr.o src/lb_fwlc.o > src/mux_pt.o src/auth.o src/fd.o src/hpack-dec.o src/memory.o src/lb_fwrr.o > src/lb_chash.o src/lb_fas.o src/hathreads.o src/chunk.o src/lb_map.o > src/xxhash.o src/regex.o src/shctx.o src/buffer.o src/action.o src/h1.o > src/compression.o src/pipe.o src/namespace.o src/sha1.o src/hpack-tbl.o > src/hpack-enc.o src/uri_auth.o src/time.o src/proto_udp.o src/arg.o > src/signal.o src/protocol.o src/lru.o src/hdr_idx.o src/hpack-huff.o > src/mailers.o src/h2.o src/base64.o src/hash.o -lnsl -lsocket -lcrypt > -L../pcre/lib -Wl,-Bstatic -lpcreposix -lpcre -Wl,-Bdynamic > Undefined first referenced > symbol in file > __sync_sub_and_fetchsrc/cache.o > __sync_val_compare_and_swap src/cache.o > __sync_lock_test_and_setsrc/cache.o > ld: fatal: symbol referencing errors. No output written to haproxy > collect2: ld returned 1 exit status > gmake: *** [haproxy] Error 1 Are you sure you did a "make clean" before building with USE_THREAD= ? Also please provide the output of "gcc --version". lukas
Re: Building HAProxy 1.8 fails on Solaris
Update: If I disable threading with USE_THREAD= then the build gets much further, but still fails eventually with: gcc -g -o haproxy src/ev_poll.o ebtree/ebtree.o ebtree/eb32sctree.o ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o src/proto_http.o src/cfgparse.o src/server.o src/stream.o src/flt_spoe.o src/stick_table.o src/stats.o src/mux_h2.o src/checks.o src/haproxy.o src/log.o src/dns.o src/peers.o src/standard.o src/sample.o src/cli.o src/stream_interface.o src/proto_tcp.o src/backend.o src/proxy.o src/tcp_rules.o src/listener.o src/flt_http_comp.o src/pattern.o src/cache.o src/filters.o src/vars.o src/acl.o src/payload.o src/connection.o src/raw_sock.o src/proto_uxst.o src/flt_trace.o src/session.o src/ev_select.o src/channel.o src/task.o src/queue.o src/applet.o src/map.o src/frontend.o src/freq_ctr.o src/lb_fwlc.o src/mux_pt.o src/auth.o src/fd.o src/hpack-dec.o src/memory.o src/lb_fwrr.o src/lb_chash.o src/lb_fas.o src/hathreads.o src/chunk.o src/lb_map.o src/xxhash.o src/regex.o src/shctx.o src/buffer.o src/action.o src/h1.o src/compression.o src/pipe.o src/namespace.o src/sha1.o src/hpack-tbl.o src/hpack-enc.o src/uri_auth.o src/time.o src/proto_udp.o src/arg.o src/signal.o src/protocol.o src/lru.o src/hdr_idx.o src/hpack-huff.o src/mailers.o src/h2.o src/base64.o src/hash.o -lnsl -lsocket -lcrypt -L../pcre/lib -Wl,-Bstatic -lpcreposix -lpcre -Wl,-Bdynamic Undefined first referenced symbol in file__sync_sub_and_fetch src/cache.o__sync_val_compare_and_swap src/cache.o__sync_lock_test_and_set src/cache.old: fatal: symbol referencing errors. No output written to haproxycollect2: ld returned 1 exit statusgmake: *** [haproxy] Error 1 On Monday, 16 July 2018, 10:52:06 am AEST, Thrawn wrote: My workplace is using HAProxy on Solaris (uname -a output: SunOS 5.10 Generic_150400-49 sun4v sparc sun4v), and we can build up to 1.7.11 successfully, but attempting to build 1.8 fails. > MAKE=/usr/sfw/bin/gmake> $MAKE cleanrm -f *.[oas] src/*.[oas] ebtree/*.[oas] > haproxy test .build_opts .build_opts.newfor dir in . src include/* doc > ebtree; do rm -f $dir/*~ $dir/*.rej $dir/core; donerm -f > haproxy-1.8.12.tar.gz haproxy-1.8.12-8a200c7.tar.gzrm -f haproxy-1.8.12 > haproxy-1.8.12-8a200c7 nohup.out gmon.out> $MAKE USE_STATIC_PCRE=1 > ARCH=native TARGET=solaris PCREDIR=../pcre/bin/sh: pcre-config: not foundgcc > -Iinclude -Iebtree -Wall -O2 -g -fno-strict-aliasing > -Wdeclaration-after-statement -fwrapv -Wno-unused-label > -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT -D_XOPEN_SOURCE=500 > -D__EXTENSIONS__ -DTPROXY -DCONFIG_HAP_CRYPT -DNEED_CRYPT_H > -DUSE_GETADDRINFO -DENABLE_POLL -DUSE_THREAD -DUSE_PCRE -I../pcre/include > -DCONFIG_HAPROXY_VERSION=\"1.8.12-8a200c7\" > -DCONFIG_HAPROXY_DATE=\"2018/06/27\" -c -o src/ev_poll.o src/ev_poll.cIn file > included from include/common/chunk.h:29, from > include/common/standard.h:36, from include/common/ticks.h:56, > from src/ev_poll.c:22:include/common/memory.h: In function > `pool_get_first':include/common/memory.h:138: warning: implicit declaration > of function `__sync_fetch_and_add'include/common/memory.h:138: warning: > implicit declaration of function `__sync_sub_and_fetch'src/ev_poll.c: In > function `_do_poll':src/ev_poll.c:235: warning: implicit declaration of > function `__sync_or_and_fetch'/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 18498: error: statement syntax/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 18498: error: statement syntax/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 18498: error: statement syntax/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 18507: error: statement syntax/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 18507: error: statement syntax/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 18507: error: statement syntax/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 2750: warning: use of DCTI couples is deprecatedgmake: *** [src/ev_poll.o] > Error 1 In case it helps, the first chunk of our 1.7.11 build output looks like: rm -f *.[oas] src/*.[oas] ebtree/*.[oas] haproxy test .build_opts .build_opts.newfor dir in . src include/* doc ebtree; do rm -f $dir/*~ $dir/*.rej $dir/core; donerm -f haproxy-1.7.11.tar.gz haproxy-1.7.11.tar.gzrm -f haproxy-1.7.11 haproxy-1.7.11 nohup.out gmon.outrm -f haproxy-systemd-wrapper/bin/sh: pcre-config: not foundgcc -Iinclude -Iebtree -Wall -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -DTPROXY -DCONFIG_HAP_CRYPT -DNEED_CRYPT_H -DUSE_GETADDRINFO -DENABLE_POLL -DUSE_PCRE -I../pcre/include -DCONFIG_HAPROXY_VERSION=\"1.7.11\" -DCONFIG_HAPROXY_DATE=\"2018/04/30\" \ -DBUILD_TARGET='"solaris"' \
Building HAProxy 1.8 fails on Solaris
My workplace is using HAProxy on Solaris (uname -a output: SunOS 5.10 Generic_150400-49 sun4v sparc sun4v), and we can build up to 1.7.11 successfully, but attempting to build 1.8 fails. > MAKE=/usr/sfw/bin/gmake> $MAKE cleanrm -f *.[oas] src/*.[oas] ebtree/*.[oas] > haproxy test .build_opts .build_opts.newfor dir in . src include/* doc > ebtree; do rm -f $dir/*~ $dir/*.rej $dir/core; donerm -f > haproxy-1.8.12.tar.gz haproxy-1.8.12-8a200c7.tar.gzrm -f haproxy-1.8.12 > haproxy-1.8.12-8a200c7 nohup.out gmon.out> $MAKE USE_STATIC_PCRE=1 > ARCH=native TARGET=solaris PCREDIR=../pcre/bin/sh: pcre-config: not foundgcc > -Iinclude -Iebtree -Wall -O2 -g -fno-strict-aliasing > -Wdeclaration-after-statement -fwrapv -Wno-unused-label > -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT -D_XOPEN_SOURCE=500 > -D__EXTENSIONS__ -DTPROXY -DCONFIG_HAP_CRYPT -DNEED_CRYPT_H > -DUSE_GETADDRINFO -DENABLE_POLL -DUSE_THREAD -DUSE_PCRE -I../pcre/include > -DCONFIG_HAPROXY_VERSION=\"1.8.12-8a200c7\" > -DCONFIG_HAPROXY_DATE=\"2018/06/27\" -c -o src/ev_poll.o src/ev_poll.cIn file > included from include/common/chunk.h:29, from > include/common/standard.h:36, from include/common/ticks.h:56, > from src/ev_poll.c:22:include/common/memory.h: In function > `pool_get_first':include/common/memory.h:138: warning: implicit declaration > of function `__sync_fetch_and_add'include/common/memory.h:138: warning: > implicit declaration of function `__sync_sub_and_fetch'src/ev_poll.c: In > function `_do_poll':src/ev_poll.c:235: warning: implicit declaration of > function `__sync_or_and_fetch'/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 18498: error: statement syntax/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 18498: error: statement syntax/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 18498: error: statement syntax/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 18507: error: statement syntax/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 18507: error: statement syntax/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 18507: error: statement syntax/usr/ccs/bin/as: "/var/tmp//ccTlH0pa.s", line > 2750: warning: use of DCTI couples is deprecatedgmake: *** [src/ev_poll.o] > Error 1 In case it helps, the first chunk of our 1.7.11 build output looks like: rm -f *.[oas] src/*.[oas] ebtree/*.[oas] haproxy test .build_opts .build_opts.newfor dir in . src include/* doc ebtree; do rm -f $dir/*~ $dir/*.rej $dir/core; donerm -f haproxy-1.7.11.tar.gz haproxy-1.7.11.tar.gzrm -f haproxy-1.7.11 haproxy-1.7.11 nohup.out gmon.outrm -f haproxy-systemd-wrapper/bin/sh: pcre-config: not foundgcc -Iinclude -Iebtree -Wall -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -DTPROXY -DCONFIG_HAP_CRYPT -DNEED_CRYPT_H -DUSE_GETADDRINFO -DENABLE_POLL -DUSE_PCRE -I../pcre/include -DCONFIG_HAPROXY_VERSION=\"1.7.11\" -DCONFIG_HAPROXY_DATE=\"2018/04/30\" \ -DBUILD_TARGET='"solaris"' \ -DBUILD_ARCH='"native"' \ -DBUILD_CPU='"generic"' \ -DBUILD_CC='"gcc"' \ -DBUILD_CFLAGS='"-O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT -D_XOPEN_SOURCE=500 -D__EXTENSIONS__"' \ -DBUILD_OPTIONS='"USE_STATIC_PCRE=1"' \ -c -o src/haproxy.o src/haproxy.c/usr/ccs/bin/as: "/var/tmp//ccmxWzXP.s", line 935: warning: use of DCTI couples is deprecated/usr/ccs/bin/as: "/var/tmp//ccmxWzXP.s", line 2632: warning: use of DCTI couples is deprecated/usr/ccs/bin/as: "/var/tmp//ccmxWzXP.s", line 6708: warning: use of DCTI couples is deprecatedgcc -Iinclude -Iebtree -Wall -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -DTPROXY -DCONFIG_HAP_CRYPT -DNEED_CRYPT_H -DUSE_GETADDRINFO -DENABLE_POLL -DUSE_PCRE -I../pcre/include -DCONFIG_HAPROXY_VERSION=\"1.7.11\" -DCONFIG_HAPROXY_DATE=\"2018/04/30\" -c -o src/base64.o src/base64.c... Is it possible to build 1.8 on our Solaris version, or is it just too old?
