Re: How to verify HAProxy build on Solaris/SPARC ?

[Tom Hood]

Hi Willy,

If I return to looking at HAProxy and decide I need its thread support,
I'll rebuild gcc with the additional enable-tls option.

Thanks for your help.
-- Tom


On Thu, Sep 6, 2018 at 8:47 PM Willy Tarreau  wrote:

> Hi Tom,
>
> On Thu, Sep 06, 2018 at 02:19:31PM -0700, Tom Hood wrote:
> > Here's the output of gcc -v
> >
> > Using built-in specs.
> > Target: sparc-sun-solaris2.8
> > Configured with: /path/to/gcc-4.2.0/configure --prefix=
> > *--enable-threads=solaris*
> > Thread model: solaris
> > gcc version: 4.2.0
>
> So I repaired my Ultra5 and booted it to try this. I had
> "--enable-threads=posix" and it didn't support "__thread" either. It
> seems it needs to be built using "--enable-tls" in addition.
>
> I wanted to upgrade my gcc using sunfreeware but sunfreeware doesn't
> exist anymore and is replaced by a paid site :-(
>
> I found alternative packages here :
>
>http://jupiterrise.com/tgcware/tgcware.solaris.html
>
> The package sources are here :
>
>https://github.com/tgc/tgcwarev2-for-solaris
>
> And you can find pre-built packages here :
>
>https://github.com/rdolbeau/tgcwarev2-solaris8-binaries
>
> I don't know if they're built with the suitable options or not.
> Alternatively there's a complete how-to explaining how to rebuild
> gcc for solaris here :
>
>
> https://lucamerello.wordpress.com/2014/05/31/solaris-10-how-to-build-and-install-gcc-4/
>
> Maybe you can use it with your gcc to attempt this (do not forget to
> add the appropriate options).
>
> Hoping this helps,
> Willy
>

Re: How to verify HAProxy build on Solaris/SPARC ?

[Willy Tarreau]

Hi Tom,

On Thu, Sep 06, 2018 at 02:19:31PM -0700, Tom Hood wrote:
> Here's the output of gcc -v
> 
> Using built-in specs.
> Target: sparc-sun-solaris2.8
> Configured with: /path/to/gcc-4.2.0/configure --prefix=
> *--enable-threads=solaris*
> Thread model: solaris
> gcc version: 4.2.0

So I repaired my Ultra5 and booted it to try this. I had
"--enable-threads=posix" and it didn't support "__thread" either. It
seems it needs to be built using "--enable-tls" in addition.

I wanted to upgrade my gcc using sunfreeware but sunfreeware doesn't
exist anymore and is replaced by a paid site :-(

I found alternative packages here :

   http://jupiterrise.com/tgcware/tgcware.solaris.html

The package sources are here :

   https://github.com/tgc/tgcwarev2-for-solaris

And you can find pre-built packages here :

   https://github.com/rdolbeau/tgcwarev2-solaris8-binaries

I don't know if they're built with the suitable options or not.
Alternatively there's a complete how-to explaining how to rebuild
gcc for solaris here :

  
https://lucamerello.wordpress.com/2014/05/31/solaris-10-how-to-build-and-install-gcc-4/

Maybe you can use it with your gcc to attempt this (do not forget to
add the appropriate options).

Hoping this helps,
Willy

Re: How to verify HAProxy build on Solaris/SPARC ?

[Tom Hood]

Here's the output of gcc -v

Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /path/to/gcc-4.2.0/configure --prefix=
*--enable-threads=solaris*
Thread model: solaris
gcc version: 4.2.0

On Sat, Sep 1, 2018 at 2:40 AM Willy Tarreau  wrote:

> On Fri, Aug 31, 2018 at 07:21:27PM -0700, Tom Hood wrote:
> > I tried Willy's suggestion with -pthread in the OPTIONS_CFLAGS and it
> > didn't make any difference.  Same errors.
> > I haven't tried looking at it anymore other than to try Willy's test.
>
> OK, thanks for the test.
>
> > Although I didn't mention it previously, I had seen that suggestion of
> > trying USE_PTHREAD_SHARED=1.  It also didn't help with 1.8.9, but I
> haven't
> > tried with 1.8.13.
>
> It will not help, it was for and old compiler not having some atomic
> builtins if I remember well.
>
> > If you think of any other tests you'd like me to try, let me know.
>
> Please send the output of "gcc -v". If it doesn't have "--enable-threads",
> you're screwed. Maybe it's present but assigned a value different from
> "posix" which is possibly not compatible.
>
> Willy
>

Re: How to verify HAProxy build on Solaris/SPARC ?

[Willy Tarreau]

On Fri, Aug 31, 2018 at 07:21:27PM -0700, Tom Hood wrote:
> I tried Willy's suggestion with -pthread in the OPTIONS_CFLAGS and it
> didn't make any difference.  Same errors.
> I haven't tried looking at it anymore other than to try Willy's test.

OK, thanks for the test.

> Although I didn't mention it previously, I had seen that suggestion of
> trying USE_PTHREAD_SHARED=1.  It also didn't help with 1.8.9, but I haven't
> tried with 1.8.13.

It will not help, it was for and old compiler not having some atomic
builtins if I remember well.

> If you think of any other tests you'd like me to try, let me know.

Please send the output of "gcc -v". If it doesn't have "--enable-threads",
you're screwed. Maybe it's present but assigned a value different from
"posix" which is possibly not compatible.

Willy

Re: How to verify HAProxy build on Solaris/SPARC ?

[Tom Hood]

Hi,

I tried Willy's suggestion with -pthread in the OPTIONS_CFLAGS and it
didn't make any difference.  Same errors.
I haven't tried looking at it anymore other than to try Willy's test.

Although I didn't mention it previously, I had seen that suggestion of
trying USE_PTHREAD_SHARED=1.  It also didn't help with 1.8.9, but I haven't
tried with 1.8.13.

If you think of any other tests you'd like me to try, let me know.

Thanks,
-- Tom


On Fri, Aug 31, 2018 at 5:24 AM Olivier Houchard 
wrote:

> Hi Lukas,
>
> On Fri, Aug 31, 2018 at 02:03:47PM +0200, Lukas Tribus wrote:
> > Hello,
> >
> >
> > On Fri, 31 Aug 2018 at 04:30, Willy Tarreau  wrote:
> > > I'd like to ask you to test something just in case it helps. Could
> > > you please modify your makefile to add "-pthread" to "-DUSE_THREAD"
> > > like this :
> > >
> > >  ifneq ($(USE_THREAD),)
> > >  BUILD_OPTIONS   += $(call ignore_implicit,USE_THREAD)
> > > -OPTIONS_CFLAGS  += -DUSE_THREAD
> > > +OPTIONS_CFLAGS  += -DUSE_THREAD -pthread
> > >  OPTIONS_LDFLAGS += -lpthread
> > >  endif
> >
> > Note that in a thread from July Oliver concluded that
> > USE_PTHREAD_PSHARED=1 is needed under Solaris:
> >
> > https://www.mail-archive.com/haproxy@formilux.org/msg30696.html
> >
> >
> > Not sure if we are talking about the same exact issue here though.
> >
>
> I think in this case it is fine, as its gcc is recent enough to have
> the required builtins.
>
> Regards,
>
> Olivier
>

Re: How to verify HAProxy build on Solaris/SPARC ?

[Olivier Houchard]

Hi Lukas,

On Fri, Aug 31, 2018 at 02:03:47PM +0200, Lukas Tribus wrote:
> Hello,
> 
> 
> On Fri, 31 Aug 2018 at 04:30, Willy Tarreau  wrote:
> > I'd like to ask you to test something just in case it helps. Could
> > you please modify your makefile to add "-pthread" to "-DUSE_THREAD"
> > like this :
> >
> >  ifneq ($(USE_THREAD),)
> >  BUILD_OPTIONS   += $(call ignore_implicit,USE_THREAD)
> > -OPTIONS_CFLAGS  += -DUSE_THREAD
> > +OPTIONS_CFLAGS  += -DUSE_THREAD -pthread
> >  OPTIONS_LDFLAGS += -lpthread
> >  endif
> 
> Note that in a thread from July Oliver concluded that
> USE_PTHREAD_PSHARED=1 is needed under Solaris:
> 
> https://www.mail-archive.com/haproxy@formilux.org/msg30696.html
> 
> 
> Not sure if we are talking about the same exact issue here though.
> 

I think in this case it is fine, as its gcc is recent enough to have
the required builtins.

Regards,

Olivier

Re: How to verify HAProxy build on Solaris/SPARC ?

[Willy Tarreau]

Hi Tom,

On Thu, Aug 30, 2018 at 05:21:04PM -0700, Tom Hood wrote:
> 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= SSL_LIB=
> (*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 -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

This is very surprising, I'm wondering whether it's possible that your
gcc was built without thread support, I don't even know if it is possible
to do this! According to this post (about a different platform), it indeed
seems it can be built without thread support :

  
https://community.hpe.com/t5/Languages-and-Scripting/thread-local-storage-doesnt-work-with-gcc/m-p/4046212#M20110

Another similar issue reported on Solaris 9 really suggests that the way
the compiler was built is important :

  https://community.oracle.com/thread/1999359

I'd like to ask you to test something just in case it helps. Could
you please modify your makefile to add "-pthread" to "-DUSE_THREAD"
like this :

 ifneq ($(USE_THREAD),)
 BUILD_OPTIONS   += $(call ignore_implicit,USE_THREAD)
-OPTIONS_CFLAGS  += -DUSE_THREAD
+OPTIONS_CFLAGS  += -DUSE_THREAD -pthread
 OPTIONS_LDFLAGS += -lpthread
 endif

It will explicitly ask gcc to enable posix thread support. I don't have
great hopes but I remember having used it on Solaris a long time ago, and
if it works we can probably add it to all targets without any harm.

> 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*)

OK, the first one can safely be ignored (though we can address it). The
second one indeed deserves a cast to make all platforms agree on the
format.

Regards,
Willy

Re: How to verify HAProxy build on Solaris/SPARC ?

[Tom Hood]

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= SSL_LIB=
(*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 -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  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  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= SSL_LIB=
>> >
>> > 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
>> >  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

Re: How to verify HAProxy build on Solaris/SPARC ?

[Tom Hood]

 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  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= SSL_LIB=
> >
> > 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
> >  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
>

Re: How to verify HAProxy build on Solaris/SPARC ?

[Willy Tarreau]

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= SSL_LIB=
> 
> 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
>  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

How to verify HAProxy build on Solaris/SPARC ?

[Tom Hood]

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.  I had to define THREAD_LOCAL to be empty in
include/common/config.h, but otherwise it seemed to build cleanly.

Build command:  gmake TARGET=solaris CPU=ultrasparc USE_OPENSSL=1
SSL_INC= SSL_LIB=

It "seems" to work for what I'm using it for on Solaris 11.3 (TCP reverse
proxy with SSL termination).

Based on forum thread regression testing for haproxy
 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?

Please let me know.

Thanks,
-- Tom