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