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 >
