Welcome! Log In Create A New Profile

Advanced

Error ‘NAME_MAX’ undeclared in HAProxy 1.8 on Solaris 11.3 (64-bit)

Posted by Daniel Heitepriem 
Hi everyone,

I tried to compile the recent HAProxy 1.8 (pulled from the git
repository) on Solaris 11.3 (x86) with these settings:
gmake TARGET=solaris CPU=generic USE_TPROXY=1 USE_ZLIB=1 USE_OPENSSL=1
USE_PCRE=1 USE_GETADDRINFO=1 USE_REGPARM=1 DEFINE="-D_XOPEN_SOURCE=600"

"-D_XOPEN_SOURCE=600" is necessary on my Solaris installation as we're
running GCC5 and the default Makefile ships with XOPEN_SOURCE=500

Despite a few warnings regarding SPIN_LOCK

<command-line>:0:0: note: this is the location of the previous
definition
In file included from include/common/memory.h:30:0,
                 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:75:0: warning: "SPIN_LOCK" redefined
 #define SPIN_LOCK(lbl, l)    do { /* do nothing */ } while(0)
 ^
In file included from /usr/include/sys/t_lock.h:15:0,
                 from /usr/include/sys/stream.h:18,
                 from /usr/include/netinet/in.h:66,
                 from /usr/include/sys/socket.h:29,
                 from include/common/compat.h:29,
                 from src/ev_poll.c:20:
/usr/include/sys/machlock.h:60:0: note: this is the location of the
previous definition
 #define SPIN_LOCK(pl) ((pl) > ipltospl(LOCK_LEVEL))


I get an error which doesn't let me compile this version of HAProxy:

src/haproxy.c: In function ‘get_old_sockets’:
src/haproxy.c:971:31: error: ‘NAME_MAX’ undeclared (first use in
this function)
  tmpbuf = malloc(fd_nb * (1 + NAME_MAX + 1 + IFNAMSIZ + sizeof(int)));
                               ^
src/haproxy.c:971:31: note: each undeclared identifier is reported
only once for each function it appears in
gmake: *** [src/haproxy.o] Error 1


Is this a known issue so far?

Thanks and regards,
Daniel
Hi Daniel,

On Fri, Nov 03, 2017 at 04:00:08PM +0100, Daniel Heitepriem wrote:
> Hi everyone,
>
> I tried to compile the recent HAProxy 1.8 (pulled from the git
> repository) on Solaris 11.3 (x86) with these settings:
> gmake TARGET=solaris CPU=generic USE_TPROXY=1 USE_ZLIB=1 USE_OPENSSL=1
> USE_PCRE=1 USE_GETADDRINFO=1 USE_REGPARM=1 DEFINE="-D_XOPEN_SOURCE=600"
>
> "-D_XOPEN_SOURCE=600" is necessary on my Solaris installation as we're
> running GCC5 and the default Makefile ships with XOPEN_SOURCE=500
>
> Despite a few warnings regarding SPIN_LOCK
>
> <command-line>:0:0: note: this is the location of the previous
> definition
> In file included from include/common/memory.h:30:0,
>                  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:75:0: warning: "SPIN_LOCK" redefined
>  #define SPIN_LOCK(lbl, l)    do { /* do nothing */ } while(0)
>  ^
> In file included from /usr/include/sys/t_lock.h:15:0,
>                  from /usr/include/sys/stream.h:18,
>                  from /usr/include/netinet/in.h:66,
>                  from /usr/include/sys/socket.h:29,
>                  from include/common/compat.h:29,
>                  from src/ev_poll.c:20:
> /usr/include/sys/machlock.h:60:0: note: this is the location of the
> previous definition
>  #define SPIN_LOCK(pl) ((pl) > ipltospl(LOCK_LEVEL))

Ah nice one, I suspected it but was glad it didn't appear. At least
we didn't test on solaris :-) I'm CCing Emeric and Christopher. Guys,
I think that we'll have to rename all of these to HA_SPIN_LOCK() as
you did for the wrappers for atomic ops.

> I get an error which doesn't let me compile this version of HAProxy:
>
> src/haproxy.c: In function 'get_old_sockets':
> src/haproxy.c:971:31: error: 'NAME_MAX' undeclared (first use in
> this function)
>   tmpbuf = malloc(fd_nb * (1 + NAME_MAX + 1 + IFNAMSIZ + sizeof(int)));
>                                ^
> src/haproxy.c:971:31: note: each undeclared identifier is reported
> only once for each function it appears in
> gmake: *** [src/haproxy.o] Error 1

Oh too bad, we've already dealt with this a long time ago but now it
reappeared in new code. CCing Olivier. Olivier, in 2012 we already
faced this issue and addressed it in commit ee2663b ("BUILD: ssl:
NAME_MAX is not portable, use MAXPATHLEN instead") but resorting to
MAXPATHLEN.

> Is this a known issue so far?

It wasn't and that was exactly the purpose of -rc1 to collect such
precious feedback! For NAME_MAX I think it can easily be redefined
by building with :

make ... DEFINE="-DNAME_MAX=MAXPATHLEN"

But for the spinlocks you'll have to modify each occurrence in many
files, which will be a real pain, so we'll have to raise this change
as a high priority in order not to wait too long without being able
to test some OSes.

Thanks very much!
Willy
Hi Willy,

when including "DEFINE="-DNAME_MAX=MAXPATHLEN"" in the build statement,
HAProxy compiles fine (leaving the warning aside).

./haproxy -vv
HA-Proxy version 1.8-rc1 2017/10/31
Copyright 2000-2017 Willy Tarreau <[email protected]>

Build options :
  TARGET  = solaris
  CPU     = generic
  CC      = gcc
  CFLAGS  = -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__ -D_XOPEN_SOURCE=600
-DNAME_MAX=MAXPATHLEN
  OPTIONS = USE_TPROXY=1 USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1
USE_OPENSSL=1 USE_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents
= 200

Built with OpenSSL version : OpenSSL 1.0.2k  26 Jan 2017
Running on OpenSSL version : OpenSSL 1.0.2k  26 Jan 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
Built with transparent proxy support using:
Built with network namespace support.
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Encrypted password support via crypt(3): yes
Built with PCRE version : 8.39 2016-06-14
Running on PCRE version : 8.39 2016-06-14
PCRE library supports JIT : no (USE_PCRE_JIT not set)

Available polling systems :
       poll : pref=200,  test result OK
     select : pref=150,  test result OK
Total: 2 (2 usable), will use poll.

Available filters :
        [SPOE] spoe
        [COMP] compression
        [TRACE] trace


Have a nice weekend,
Daniel

Am 03.11.2017 um 23:08 schrieb Willy Tarreau:
> Hi Daniel,
>
> It wasn't and that was exactly the purpose of -rc1 to collect such
> precious feedback! For NAME_MAX I think it can easily be redefined
> by building with :
>
> make ... DEFINE="-DNAME_MAX=MAXPATHLEN"
>
> But for the spinlocks you'll have to modify each occurrence in many
> files, which will be a real pain, so we'll have to raise this change
> as a high priority in order not to wait too long without being able
> to test some OSes.
>
> Thanks very much!
> Willy
On Fri, Nov 03, 2017 at 11:17:25PM +0100, Daniel Heitepriem wrote:
> Hi Willy,
>
> when including "DEFINE="-DNAME_MAX=MAXPATHLEN"" in the build statement,
> HAProxy compiles fine (leaving the warning aside).

Cool, thank you for the report.

willy
Hi guys,

On Fri, Nov 03, 2017 at 11:08:03PM +0100, Willy Tarreau wrote:
> > I get an error which doesn't let me compile this version of HAProxy:
> >
> > src/haproxy.c: In function 'get_old_sockets':
> > src/haproxy.c:971:31: error: 'NAME_MAX' undeclared (first use in
> > this function)
> > ? tmpbuf = malloc(fd_nb * (1 + NAME_MAX + 1 + IFNAMSIZ + sizeof(int)));
> > ?????????????????????????????? ^
> > src/haproxy.c:971:31: note: each undeclared identifier is reported
> > only once for each function it appears in
> > gmake: *** [src/haproxy.o] Error 1
>
> Oh too bad, we've already dealt with this a long time ago but now it
> reappeared in new code. CCing Olivier. Olivier, in 2012 we already
> faced this issue and addressed it in commit ee2663b ("BUILD: ssl:
> NAME_MAX is not portable, use MAXPATHLEN instead") but resorting to
> MAXPATHLEN.
>

The attached patch should fix that.
Sorry about that, I remember trying to figure out what the right spelling was,
quite obviously I was wrong :)
But shouldn't it be PATH_MAX, which seems to be defined by POSIX ?

Regards,

Olivier
From 02b1a8886d80814ebcb3eb02b2f635fb780ee14e Mon Sep 17 00:00:00 2001
From: Olivier Houchard <[email protected]>
Date: Sat, 4 Nov 2017 15:13:01 +0100
Subject: [PATCH] BUILD: use MAXPATHLEN instead of NAME_MAX.

This fixes building on at least Solaris, where NAME_MAX doesn't exist.
---
src/cli.c | 2 +-
src/haproxy.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/cli.c b/src/cli.c
index b546fd02b..9c7794945 100644
--- a/src/cli.c
+++ b/src/cli.c
@@ -1354,7 +1354,7 @@ static int _getsocks(char **args, struct appctx *appctx, void *private)
/* We will send sockets MAX_SEND_FD per MAX_SEND_FD, allocate a
* buffer big enough to store the socket informations.
*/
- tmpbuf = malloc(MAX_SEND_FD * (1 + NAME_MAX + 1 + IFNAMSIZ + sizeof(int)));
+ tmpbuf = malloc(MAX_SEND_FD * (1 + MAXPATHLEN + 1 + IFNAMSIZ + sizeof(int)));
if (tmpbuf == NULL) {
Warning("Failed to allocate memory to transfer socket informations\n");
goto out;
diff --git a/src/haproxy.c b/src/haproxy.c
index d3db264ee..68b5e427b 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -968,7 +968,7 @@ static int get_old_sockets(const char *unixsocket)
ret = 0;
goto out;
}
- tmpbuf = malloc(fd_nb * (1 + NAME_MAX + 1 + IFNAMSIZ + sizeof(int)));
+ tmpbuf = malloc(fd_nb * (1 + MAXPATHLEN + 1 + IFNAMSIZ + sizeof(int)));
if (tmpbuf == NULL) {
Warning("Failed to allocate memory while receiving sockets\n");
goto out;
@@ -980,7 +980,7 @@ static int get_old_sockets(const char *unixsocket)
}
msghdr.msg_control = cmsgbuf;
msghdr.msg_controllen = CMSG_SPACE(sizeof(int)) * MAX_SEND_FD;
- iov.iov_len = MAX_SEND_FD * (1 + NAME_MAX + 1 + IFNAMSIZ + sizeof(int));
+ iov.iov_len = MAX_SEND_FD * (1 + MAXPATHLEN + 1 + IFNAMSIZ + sizeof(int));
do {
int ret3;

--
2.13.5
Hi Olivier,

On Sat, Nov 04, 2017 at 03:17:59PM +0100, cognet wrote:
> > Oh too bad, we've already dealt with this a long time ago but now it
> > reappeared in new code. CCing Olivier. Olivier, in 2012 we already
> > faced this issue and addressed it in commit ee2663b ("BUILD: ssl:
> > NAME_MAX is not portable, use MAXPATHLEN instead") but resorting to
> > MAXPATHLEN.
> >
>
> The attached patch should fix that.

Thanks, now applied.

> Sorry about that, I remember trying to figure out what the right spelling was,
> quite obviously I was wrong :)

It's always the problem when several such variables work on a given platform.

> But shouldn't it be PATH_MAX, which seems to be defined by POSIX ?

Very likely, yes, but I seem to remember something about it being declared
to be a very different size than the other ones on some older libc, which
might have explained why we sticked to MAXPATHLEN by then.

Willy
Hi guys,

I can confirm that the patch is working. With the following loop I
replaced the string "SPIN_LOCK" with "HA_SPIN_LOCK" in every file where
it occured (I hope I got every file) and now compilation is working fine
(gnu sed is required):

for file in include/common/buffer.h include/common/hathreads.h
include/common/memory.h include/proto/applet.h
include/proto/channel.h include/proto/checks.h include/proto/fd.h
include/proto/stick_table.h include/proto/stream.h
include/proto/task.h src/applet.c src/checks.c src/compression.c
src/dns.c src/ev_epoll.c src/ev_kqueue.c src/ev_poll.c
src/ev_select.c src/fd.c src/flt_spoe.c src/hathreads.c
src/hlua_fcn.c src/hlua.c src/lb_chash.c src/lb_fas.c src/lb_fwlc.c
src/lb_fwrr.c src/lb_map.c src/listener.c src/map.c src/memory.c
src/mux_h2.c src/pattern.c src/peers.c src/proto_http.c src/queue.c
src/server.c src/stats.c src/stick_table.c src/stream.c src/task.c;
do gsed -i 's/SPIN_LOCK/HA_SPIN_LOCK/g' $file; done


Regards,
Daniel

Am 04.11.2017 um 17:10 schrieb Willy Tarreau:
> Hi Olivier,
>
> On Sat, Nov 04, 2017 at 03:17:59PM +0100, cognet wrote:
>>> Oh too bad, we've already dealt with this a long time ago but now it
>>> reappeared in new code. CCing Olivier. Olivier, in 2012 we already
>>> faced this issue and addressed it in commit ee2663b ("BUILD: ssl:
>>> NAME_MAX is not portable, use MAXPATHLEN instead") but resorting to
>>> MAXPATHLEN.
>>>
>> The attached patch should fix that.
> Thanks, now applied.
>
>> Sorry about that, I remember trying to figure out what the right spelling was,
>> quite obviously I was wrong :)
> It's always the problem when several such variables work on a given platform.
>
>> But shouldn't it be PATH_MAX, which seems to be defined by POSIX ?
> Very likely, yes, but I seem to remember something about it being declared
> to be a very different size than the other ones on some older libc, which
> might have explained why we sticked to MAXPATHLEN by then.
>
> Willy
Hi Daniel,

On Sun, Nov 05, 2017 at 02:58:23PM +0100, Daniel Heitepriem wrote:
> Hi guys,
>
> I can confirm that the patch is working. With the following loop I replaced
> the string "SPIN_LOCK" with "HA_SPIN_LOCK" in every file where it occured (I
> hope I got every file) and now compilation is working fine (gnu sed is
> required):
>
> for file in include/common/buffer.h include/common/hathreads.h
> include/common/memory.h include/proto/applet.h
> include/proto/channel.h include/proto/checks.h include/proto/fd.h
> include/proto/stick_table.h include/proto/stream.h
> include/proto/task.h src/applet.c src/checks.c src/compression.c
> src/dns.c src/ev_epoll.c src/ev_kqueue.c src/ev_poll.c
> src/ev_select.c src/fd.c src/flt_spoe.c src/hathreads.c
> src/hlua_fcn.c src/hlua.c src/lb_chash.c src/lb_fas.c src/lb_fwlc.c
> src/lb_fwrr.c src/lb_map.c src/listener.c src/map.c src/memory.c
> src/mux_h2.c src/pattern.c src/peers.c src/proto_http.c src/queue.c
> src/server.c src/stats.c src/stick_table.c src/stream.c src/task.c;
> do gsed -i 's/SPIN_LOCK/HA_SPIN_LOCK/g' $file; done


Thanks, that's very useful. We'll have to do this and we'll then also
enable threads by default on Solaris.

Many thanks for your report!
Willy
Sorry, only registered users may post in this forum.

Click here to login