Hi Willy, I downloaded 1.8.13 and tried the following build command (again on the same Solaris 10 box, same gcc 4.2.0). The CC=/path/to/bin/gcc was also on the 1.8.9 build line I used previously.
gmake CC=/path/to/bin/gcc TARGET=solaris CPU=ultrasparc USE_OPENSSL=1 SSL_INC=<includepath> SSL_LIB=<libpath> (*beware of possible typos in the following output*) /path/to/bin/gcc -Iinclude -Iebtree -Wall -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv -fno-strict-overflow -Wno-unused-label -fomit-frame-pointer -DFD_SETSIZE=65536 -D_RENTRANT -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -DTPROXY -DCONFIG_HAP_CRYPT -DNEED_CRYPT_H -DUSE_GETADDRINFO -DENABLE_POLL -DUSE_THREAD -DUSE_OPENSSL -I<sslincludepath> -DCONFIG_HAPROXY_VERSION=\"1.8.13\" -DCONFIG_HAPROXY_DATE=\"2018/07/30\" -c -o src/ev_poll.o src/ev_poll.c In file included from include/common/memory.h:32, 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/hathreads.h:28: error: thread-local-storage not supported for this target include/common/hathreads.h:29: error: thread-local-storage not supported for this target In file included from include/common/ticks.h:56, from src/ev_poll.c:22 include/common/standard.h:96: error: thread-local-storage not supported for this target include/common/standard.h:111: error: thread-local-storage not supported for this target (*etc. lots more of same errors*) If I add USE_THREAD= to the gmake command, everything builds cleanly with the exception of 2 warnings: src/proto_http.c:384: warning: type qualifiers ignored on function return type (*the "const" isn't useful there*) src/haproxy.c:2813: warning: format '%d' expects type 'int', but argument 4 has type 'pid_t' (*should probably use %ld instead*) -- Tom On Thu, Aug 30, 2018 at 8:40 AM Tom Hood <[email protected]> wrote: > Hi Willy, > > Thanks for the reply. > > I should have stated that I'm not at a point of trying to install or > deploy haproxy, yet. I'm starting to evaluate haproxy and some other > products that can run on Solaris/SPARC as TCP reverse proxies with SSL > termination. I will also look at stunnel and nginx. > > I wasn't able to find any documented post-build verification step that > will run through a battery of automated haproxy regression tests. Is there > such a thing in the 1.8 branch? > > Yes, writing automated tests for different race conditions involving > concurrent threads is tricky. In our app we do a combination of stress > tests that run for long periods of time combined with instrumented code in > places to raise and lower barriers to force a particular sequence of thread > execution to help verify synchronization is working as intended. That > said, I didn't intend to limit my question to thread testing of the build. > > When I get to work later today I'll see if I can provide you more detail > on the issue I encountered with __thread. I doubt we will have any need to > run with threads so building without thread support is an option, too. > > Thanks, > -- Tom > > On Wed, Aug 29, 2018 at 8:29 PM Willy Tarreau <[email protected]> wrote: > >> Hi Tom, >> >> On Wed, Aug 29, 2018 at 05:05:20PM -0700, Tom Hood wrote: >> > Hi, >> > >> > I've built haproxy 1.8.9 with gcc 4.2.0 on Solaris 10, but I'm not sure >> how >> > to verify my build. >> >> Well, first and foremost, you must absolutely use an up-to-date version >> in the branch you choose. Latest version in the 1.8 branch currently is >> 1.8.13 so there is no reason to purposely install a version containing a >> number of well known bugs that were already fixed in more recent versions. >> >> > I had to define THREAD_LOCAL to be empty in >> > include/common/config.h, but otherwise it seemed to build cleanly. >> >> I find this strange because it is already defined as empty there if >> USE_THREAD is not set. And if USE_THREAD is set, you absolutely need >> to have this defined to __thread as it's a compiler indication that >> the variable is thread-local (per thread) instead of shared. >> >> > Build command: gmake TARGET=solaris CPU=ultrasparc USE_OPENSSL=1 >> > SSL_INC=<includepath> SSL_LIB=<libpath> >> > >> > It "seems" to work for what I'm using it for on Solaris 11.3 (TCP >> reverse >> > proxy with SSL termination). >> >> If you're using threads it will definitely fail without __thread. >> >> > Based on forum thread regression testing for haproxy >> > <https://www.mail-archive.com/[email protected]/msg30287.html> it >> looks >> > like maybe there isn't any automated testing of my haproxy build I can >> do >> > yet? >> > >> > I see the "tests" directory, but I'm not sure what I'm supposed to do >> with >> > that. I don't see any expected result files for each test case? >> >> The problem with threads is that it solely relies on luck, so by >> definition >> it's hard to build a test to verify that what you've built uses correct >> locking. The simple fact that it did not build and you had to modify it >> is the problematic part. If you don't need threads, please try to build >> adding "USE_THREAD=" (no value) to your make command to disable use of >> threads. At least you will not risk to face any thread-related issue. >> However I'm definitely interested in figuring why __thread does not >> work there! At least from what I'm reading below, it is expected to >> work just like on any other system : >> >> https://docs.oracle.com/cd/E26502_01/html/E26507/gentextid-23018.html >> >> Regards, >> Willy >> >
