Re: [ANNOUNCE] haproxy-1.4.0
On 2010-03-03 23:12, Willy Tarreau wrote: On Wed, Mar 03, 2010 at 01:02:16AM +0100, Krzysztof Ol??dzki wrote: On 2010-03-03 00:47, Willy Tarreau wrote: On Wed, Mar 03, 2010 at 12:39:48AM +0100, Willy Tarreau wrote: Finally, encryption was only tested on Linux and FreeBSD so it could be nice to verify if it works on Solaris in the same way (with -lcrypt) and to add USE_LIBCRYPT for "ifeq ($(TARGET),solaris)". OK I'm testing it now then and will keep you informed. it builds with the same warning as we had on linux, despite the man not mentioning anything specific. :( Did you include unistd.h? If so, could you try defining _XOPEN_SOURCE to 600? Yes unistd.h is included as indicated in the man page, but still the warning. I've tried with _XOPEN_SOURCE set to 600 and it reported even more errors than with 500. In fact, any value other than 500 reports a huge number of errors in many includes files. So in the end I've added a new build option USE_CRYPT_H which for now I only set by default for solaris (though it works on linux, various toolchains except dietlibc). It will make it easy to enable it for other systems if required. Using the following patch I can build it everywhere here without a warning. Could you please test on your various FreeBSD versions, I see no reason why it should change anything, it's just for the sake of completeness. Ack, Ack. Sorry for the delay. I know that you have already merged this patch and released a new version. ;) Best regards, Krzysztof Olędzki
Re: [ANNOUNCE] haproxy-1.4.0
Hi guys, On Wed, Mar 03, 2010 at 07:05:28AM +0100, Willy Tarreau wrote: > On Wed, Mar 03, 2010 at 01:02:16AM +0100, Krzysztof Ol??dzki wrote: > > On 2010-03-03 00:47, Willy Tarreau wrote: > > >On Wed, Mar 03, 2010 at 12:39:48AM +0100, Willy Tarreau wrote: > > >>>Finally, encryption was only tested on Linux and FreeBSD so it could be > > >>>nice to verify if it works on Solaris in the same way (with -lcrypt) and > > >>>to add USE_LIBCRYPT for "ifeq ($(TARGET),solaris)". > > >> > > >>OK I'm testing it now then and will keep you informed. > > > > > >it builds with the same warning as we had on linux, despite the > > >man not mentioning anything specific. Just for the record, I've merged Krzysztof's patch making use of _GNU_SOURCE and I've added the NEED_CRYPT_H build option for Solaris. It fixed the build on two Solaris 8 machines for me. I tried on AIX 5.3 (TARGET=generic) and it built without any warning. On Linux, uclibc, glibc 2.2.5, 2.3.6 and 2.7 are OK. FreeBSD 4 to 8 are reportedly OK. So I'm confident that we're OK for quite some time now. Thanks very much for your tests and involvement in getting this issue solved. Regards, Willy
Re: [ANNOUNCE] haproxy-1.4.0
On Thu, Mar 04, 2010 at 09:53:44AM -0500, Ross West wrote: > > WT> Using the following patch I can build it everywhere here without a > WT> warning. Could you please test on your various FreeBSD versions, I > WT> see no reason why it should change anything, it's just for the sake > WT> of completeness. > > Compiles without error on FB 7+8! Thanks for checking Ross ! Cheers, Willy
Re: [ANNOUNCE] haproxy-1.4.0
On Wed, Mar 03, 2010 at 01:02:16AM +0100, Krzysztof Ol??dzki wrote: > On 2010-03-03 00:47, Willy Tarreau wrote: > >On Wed, Mar 03, 2010 at 12:39:48AM +0100, Willy Tarreau wrote: > >>>Finally, encryption was only tested on Linux and FreeBSD so it could be > >>>nice to verify if it works on Solaris in the same way (with -lcrypt) and > >>>to add USE_LIBCRYPT for "ifeq ($(TARGET),solaris)". > >> > >>OK I'm testing it now then and will keep you informed. > > > >it builds with the same warning as we had on linux, despite the > >man not mentioning anything specific. > > :( Did you include unistd.h? If so, could you try defining _XOPEN_SOURCE > to 600? Yes unistd.h is included as indicated in the man page, but still the warning. I've tried with _XOPEN_SOURCE set to 600 and it reported even more errors than with 500. In fact, any value other than 500 reports a huge number of errors in many includes files. So in the end I've added a new build option USE_CRYPT_H which for now I only set by default for solaris (though it works on linux, various toolchains except dietlibc). It will make it easy to enable it for other systems if required. Using the following patch I can build it everywhere here without a warning. Could you please test on your various FreeBSD versions, I see no reason why it should change anything, it's just for the sake of completeness. Thanks ! Willy diff --git a/Makefile b/Makefile index 022731d..4c13355 100644 --- a/Makefile +++ b/Makefile @@ -20,6 +20,8 @@ # USE_TPROXY : enable transparent proxy. Automatic. # USE_LINUX_TPROXY : enable full transparent proxy (need kernel patch). # USE_LINUX_SPLICE : enable kernel 2.6 splicing (broken on old kernels) +# USE_LIBCRYPT : enable crypted passwords using -lcrypt +# USE_CRYPT_H : set it if your system requires including crypt.h # # Options can be forced by specifying "USE_xxx=1" or can be disabled by using # "USE_xxx=" (empty string). @@ -208,6 +210,8 @@ ifeq ($(TARGET),solaris) TARGET_CFLAGS = -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT TARGET_LDFLAGS = -lnsl -lsocket USE_TPROXY = implicit + USE_LIBCRYPT= implicit + USE_CRYPT_H = implicit else ifeq ($(TARGET),freebsd) # This is for FreeBSD @@ -336,6 +340,11 @@ BUILD_OPTIONS += $(call ignore_implicit,USE_LIBCRYPT) OPTIONS_LDFLAGS += -lcrypt endif +ifneq ($(USE_CRYPT_H),) +OPTIONS_CFLAGS += -DNEED_CRYPT_H +BUILD_OPTIONS += $(call ignore_implicit,USE_CRYPT_H) +endif + ifneq ($(USE_POLL),) OPTIONS_CFLAGS += -DENABLE_POLL OPTIONS_OBJS += src/ev_poll.o diff --git a/src/auth.c b/src/auth.c index 93af8d6..5fecca5 100644 --- a/src/auth.c +++ b/src/auth.c @@ -10,7 +10,12 @@ * */ -#define _XOPEN_SOURCE 500 +/* This is to have crypt() defined on Linux */ +#define _GNU_SOURCE + +#ifdef NEED_CRYPT_H +#include +#endif #include #include
Re: [ANNOUNCE] haproxy-1.4.0
On Wed, Mar 03, 2010 at 10:25:17AM -0500, Ross West wrote: > Good morning everyone, > > WT> I hope you don't mind that I CC the list and Krzysztof who needed > WT> the line which caused the problem on your side. > > No problem, I just hit reply, rather than reply-all out of habit. > > >> However, instead of using _XOPEN_SOURCE we may use something less > >> invasive (I hope), like for example _GNU_SOURCE. > >> > >> Could you please check, if it helps? Also, there is no point in > >> including unistd.c and adding one of the above defines for crypt() if > >> CONFIG_HAP_CRYPT is not defined. So, the final fix may look like this: > > WT> Let's wait for Ross to test on FreeBSD and if that's OK, I apply > WT> the patch and release 1.4.1. > > Applying Krzysztof's patch worked on both FB 7.0 and FB 8.0 for me! OK thanks for your confirmation. Apparently Krzysztof also has a bunch of FreeBSD versions and observed a similar positive result. We just need a proper fix for the same initial warning on Solaris and we're done. Thanks, Willy
Re: [ANNOUNCE] haproxy-1.4.0
On Wed, Mar 03, 2010 at 01:02:16AM +0100, Krzysztof Ol??dzki wrote: > On 2010-03-03 00:47, Willy Tarreau wrote: > >On Wed, Mar 03, 2010 at 12:39:48AM +0100, Willy Tarreau wrote: > >>>Finally, encryption was only tested on Linux and FreeBSD so it could be > >>>nice to verify if it works on Solaris in the same way (with -lcrypt) and > >>>to add USE_LIBCRYPT for "ifeq ($(TARGET),solaris)". > >> > >>OK I'm testing it now then and will keep you informed. > > > >it builds with the same warning as we had on linux, despite the > >man not mentioning anything specific. > > :( Did you include unistd.h? If so, could you try defining _XOPEN_SOURCE > to 600? > > >However, on solaris, crypt() > >is defined in crypt.h, which I also have here on linux and which > >is in some of my old programs which made use of crypt(). > > Blah... This shows why configure is so popular... :| Popular... among developers because it saves them from searching. It's commonly hated among users because it works 50% of the time, and the other 50% it's a hell to debug or to find a way to force your options. > >Ross, it would be nice if you could check on FreeBSD if we have > >crypt.h available. Probably that we should make use of it by > >default and not rely on the "standard" includes which are only > >there for compatibility with specific programs which define > >_XOPEN_SOURCE. > > I have several FreeBSD servers - 4.x, 5.x, 6.x, 7.x, and 8.x. None of > them have crypt.h. :( OK thanks for checking. So maybe we could define a NEED_CRYPT_H macro in the makefile for linux and solaris and not for other OSes right now. Regards, Willy
Re: [ANNOUNCE] haproxy-1.4.0
On 2010-03-03 00:47, Willy Tarreau wrote: On Wed, Mar 03, 2010 at 12:39:48AM +0100, Willy Tarreau wrote: Finally, encryption was only tested on Linux and FreeBSD so it could be nice to verify if it works on Solaris in the same way (with -lcrypt) and to add USE_LIBCRYPT for "ifeq ($(TARGET),solaris)". OK I'm testing it now then and will keep you informed. it builds with the same warning as we had on linux, despite the man not mentioning anything specific. :( Did you include unistd.h? If so, could you try defining _XOPEN_SOURCE to 600? However, on solaris, crypt() is defined in crypt.h, which I also have here on linux and which is in some of my old programs which made use of crypt(). Blah... This shows why configure is so popular... :| Ross, it would be nice if you could check on FreeBSD if we have crypt.h available. Probably that we should make use of it by default and not rely on the "standard" includes which are only there for compatibility with specific programs which define _XOPEN_SOURCE. I have several FreeBSD servers - 4.x, 5.x, 6.x, 7.x, and 8.x. None of them have crypt.h. :( Best regards, Krzysztof Olędzki
Re: [ANNOUNCE] haproxy-1.4.0
On Wed, Mar 03, 2010 at 12:39:48AM +0100, Willy Tarreau wrote: > > Finally, encryption was only tested on Linux and FreeBSD so it could be > > nice to verify if it works on Solaris in the same way (with -lcrypt) and > > to add USE_LIBCRYPT for "ifeq ($(TARGET),solaris)". > > OK I'm testing it now then and will keep you informed. it builds with the same warning as we had on linux, despite the man not mentioning anything specific. However, on solaris, crypt() is defined in crypt.h, which I also have here on linux and which is in some of my old programs which made use of crypt(). Ross, it would be nice if you could check on FreeBSD if we have crypt.h available. Probably that we should make use of it by default and not rely on the "standard" includes which are only there for compatibility with specific programs which define _XOPEN_SOURCE. After all, if we have to link with -lcrypt, it makes sense to require the associated include. Willy
Re: [ANNOUNCE] haproxy-1.4.0
Hi Krzysztof,
On Wed, Mar 03, 2010 at 12:29:01AM +0100, Krzysztof Ol??dzki wrote:
> First, sorry for the problem I have made. :(
hey please don't be sorry, here we say that we don't make
omelettes without breaking eggs :-)
> Accoriding to crypt(3) from man-pages-3.21 it is required to define
> _XOPEN_SOURCE:
I've seen this man page but it does not reflect anything I've seen
on any other system, nor even what is required on my machines !
...
Oh sorry, I did not build the test program with -Wall. Shame on me!
Yes I now do see the same one on linux with glibc 2.7 :-(
(...)
> This short program proves the man page is right:
>
> --- ctest.c begin ---
> #include
>
> int main() {
> char *c;
>
> crypt(c, c);
>
> return 0;
> }
> --- ctest.c end ---
>
> $ cc ctest.c -o ctest -Wall -lcrypt ; echo $?
> ctest.c: In function 'main':
> ctest.c:6: warning: implicit declaration of function 'crypt'
> 0
>
> $ cc ctest.c -o ctest -Wall -lcrypt -D_XOPEN_SOURCE ; echo $?
> 0
>
> It behaves exactly in the same way on glibc-2.7, 2.8 and 2.9 on both
> i386 and x86-64.
>
> In /usr/include/unistd.h I found:
>
> >#ifdef __USE_XOPEN
> >/* Encrypt at most 8 characters from KEY using salt to perturb DES. */
> >extern char *crypt (__const char *__key, __const char *__salt)
> > __THROW __nonnull ((1, 2));
>
> (...)
>
> __USE_XOPEN is defined in features.h:
>
> >#ifdef _XOPEN_SOURCE
> ># define __USE_XOPEN1
> (...)
>
> However, instead of using _XOPEN_SOURCE we may use something less
> invasive (I hope), like for example _GNU_SOURCE.
>
> Could you please check, if it helps? Also, there is no point in
> including unistd.c and adding one of the above defines for crypt() if
> CONFIG_HAP_CRYPT is not defined. So, the final fix may look like this:
You rock :-)
Here on linux glibc-2.7, it does not cause any warning (not either
for strdup which you initially had). Solaris 8 builds without a
warning too.
Let's wait for Ross to test on FreeBSD and if that's OK, I apply
the patch and release 1.4.1.
>
> --- cut here ---
> index 93af8d6..b00727f 100644
> --- a/src/auth.c
> +++ b/src/auth.c
> @@ -10,12 +10,14 @@
> *
> */
>
> -#define _XOPEN_SOURCE 500
> +#ifdef CONFIG_HAP_CRYPT
> +#define _GNU_SOURCE
> +#include
> +#endif
>
> #include
> #include
> #include
> -#include
>
> #include
> --- cut here ---
>
> Finally, encryption was only tested on Linux and FreeBSD so it could be
> nice to verify if it works on Solaris in the same way (with -lcrypt) and
> to add USE_LIBCRYPT for "ifeq ($(TARGET),solaris)".
OK I'm testing it now then and will keep you informed.
Thanks,
Willy
Re: [ANNOUNCE] haproxy-1.4.0
On 2010-03-02 23:43, Willy Tarreau wrote:
Hi Holger,
Hi Willy,
Hi Holer,
I could get the same errors on my ultra5 under solaris 8
which correctly builds 1.3. I finally tracked that down to
the #define XOPEN_SOURCE 500 in auth.c. If I remove it,
everything builds as before.
Krzysztof, you told me you had to add it otherwise you got a
warning on your platform with crypt() not being defined. Could
you check if you manage to get rid of the warning by adding a
few common #includes ? The only case I had to add such #defines
was when porting code from very old unixes to linux, but generally
those defines are needed as last resort portability tricks. And
since the crypt() function has been there for decades, I find it
strange that we absolutely need such a define.
First, sorry for the problem I have made. :(
Accoriding to crypt(3) from man-pages-3.21 it is required to define
_XOPEN_SOURCE:
(...)
SYNOPSIS
#define _XOPEN_SOURCE
#include
char *crypt(const char *key, const char *salt);
(...)
This short program proves the man page is right:
--- ctest.c begin ---
#include
int main() {
char *c;
crypt(c, c);
return 0;
}
--- ctest.c end ---
$ cc ctest.c -o ctest -Wall -lcrypt ; echo $?
ctest.c: In function 'main':
ctest.c:6: warning: implicit declaration of function 'crypt'
0
$ cc ctest.c -o ctest -Wall -lcrypt -D_XOPEN_SOURCE ; echo $?
0
It behaves exactly in the same way on glibc-2.7, 2.8 and 2.9 on both
i386 and x86-64.
In /usr/include/unistd.h I found:
#ifdef __USE_XOPEN
/* Encrypt at most 8 characters from KEY using salt to perturb DES. */
extern char *crypt (__const char *__key, __const char *__salt)
__THROW __nonnull ((1, 2));
(...)
__USE_XOPEN is defined in features.h:
#ifdef _XOPEN_SOURCE
# define __USE_XOPEN1
(...)
However, instead of using _XOPEN_SOURCE we may use something less
invasive (I hope), like for example _GNU_SOURCE.
Could you please check, if it helps? Also, there is no point in
including unistd.c and adding one of the above defines for crypt() if
CONFIG_HAP_CRYPT is not defined. So, the final fix may look like this:
--- cut here ---
index 93af8d6..b00727f 100644
--- a/src/auth.c
+++ b/src/auth.c
@@ -10,12 +10,14 @@
*
*/
-#define _XOPEN_SOURCE 500
+#ifdef CONFIG_HAP_CRYPT
+#define _GNU_SOURCE
+#include
+#endif
#include
#include
#include
-#include
#include
--- cut here ---
Finally, encryption was only tested on Linux and FreeBSD so it could be
nice to verify if it works on Solaris in the same way (with -lcrypt) and
to add USE_LIBCRYPT for "ifeq ($(TARGET),solaris)".
Best regards,
Krzysztof Olędzki
Re: [ANNOUNCE] haproxy-1.4.0
Hi Willy, On 2010-03-02 23:43, Willy Tarreau wrote: > I could get the same errors on my ultra5 under solaris 8 > which correctly builds 1.3. I finally tracked that down to > the #define XOPEN_SOURCE 500 in auth.c. If I remove it, > everything builds as before. just for the archives: 1.3 also compiles fine at my Opensolaris box. So if I can help in solving the 1.4 issues I will happily try to do so. Anyways: Thank you and all the other guys for the support and this great piece of software :) --Holger
Re: [ANNOUNCE] haproxy-1.4.0
Hi Ross, I hope you don't mind that I CC the list and Krzysztof who needed the line which caused the problem on your side. On Tue, Mar 02, 2010 at 05:36:05PM -0500, Ross West wrote: > > WT> Please tell me if the above works. If so, just send me a patch and I'll > WT> happily apply it. I still have to start my Sun in order to fix the build > WT> on Solaris, and I'd like to release 1.4.1 with those build fixes in it. > > The two additions didn't work, but I've tracked it down. The good > news is that it's not really your bug, but FreeBSD's, which got fixed > in 8.0. > > The issue is the inclusion of the "#define _XOPEN_SOURCE 500" in > auth.c. Hehe interesting, I just converged to the same line for the solaris build issue. > On older FB versions (ie: below 8.0), it triggers a change in > sys/types.h to not include sys/select.h. sys/time.h was modified > starting in FB 8.0+ to include sys/select.h always. > > Basically as someone else mentioned: "The problem lies in FreeBSD's > headers, which don't implement namespace separation correctly." > > In which case I'll just write a simple patch that I'll include with > the port build which can add an "#include " line to > auth.c for older OS versions. Well, we're on pretty standard code and I'd rather avoid as much as possible OS version tests on such code, as we all know how it ends up in unmanageable chunks of code depending on autoconf and making us all pull off our hair. I also don't like adding an include which is unrelated to the parts used by a C file. However we may need that include into the file which needs it (standard.h at least since it's the one making use of fd_set). If it's the XOPEN_SOURCE line which is causing these issues, either we manage to push it a bit below, which will make things work by pure luck, or we find how to get rid of it, which would be preferred, considering that this line alone apparently breaks solaris and freebsd, which does not surprize me much given the bad experiences I had with such defines :-/ > IMHO, it's not really your bug to fix. Well, it is if we break several platforms to try to fix a warning on another one. Maybe it's the another one which is buggy instead. Also if we only need this line to get crypt() to be defined on some linux platforms, maybe we can also define it ourselves. Thanks, Willy
Re: [ANNOUNCE] haproxy-1.4.0
Hi Holger, I could get the same errors on my ultra5 under solaris 8 which correctly builds 1.3. I finally tracked that down to the #define XOPEN_SOURCE 500 in auth.c. If I remove it, everything builds as before. Krzysztof, you told me you had to add it otherwise you got a warning on your platform with crypt() not being defined. Could you check if you manage to get rid of the warning by adding a few common #includes ? The only case I had to add such #defines was when porting code from very old unixes to linux, but generally those defines are needed as last resort portability tricks. And since the crypt() function has been there for decades, I find it strange that we absolutely need such a define. Thanks, Willy
Re: [ANNOUNCE] haproxy-1.4.0
Hi Holger,
On Sun, Feb 28, 2010 at 11:16:01AM +0100, Holger Just wrote:
> Hi Willy,
>
> On 2010-02-28 07:29, Willy Tarreau wrote:
> > Could you please try to add the two following lines at the top of the
> > 3 faulty files (types/session.h, types/proxy.h, types/protocols.h) :
> >
> > #include
> > #include
> >
> > I think it should fix the build.
>
> Thanks for your help. Unfortunately, it did not work. The errors are
> exactly the same.
>
> I noticed though, that the definition of sockaddr_storage in
> /usr/include/sys/socket_impl.h looks like this:
>
>
> #if !defined(_XPG4_2) || defined(_XPG6) || defined(__EXTENSIONS__)
> [...]
> struct sockaddr_storage {
> sa_family_t ss_family; /* Address family */
> /* Following fields are implementation specific */
> char_ss_pad1[_SS_PAD1SIZE];
> sockaddr_maxalign_t _ss_align;
> char_ss_pad2[_SS_PAD2SIZE];
> };
> #endif
>
>
> So if I add SILENT_DEFINE="-D__EXTENSIONS__=1" to the make call gcc does
> not complain anymore (even without adding the additional includes). I'm
> not currently able to decide if the resulting executable is completely
> valid or if this is a valid approach even.
Interesting. However, at least one of those defines is already present
elsewhere because 1.3 correctly builds on solaris and already supports
IPv6. The SuSv4 specification says that socket.h should be enough, but
given the part you have spotted above, clearly something else is missing.
I'll have to unpack my ultra5 and replug it to test. I'd really like to
get this definitely sorted out.
Regards,
Willy
Re: [ANNOUNCE] haproxy-1.4.0
Hi Willy,
On 2010-02-28 07:29, Willy Tarreau wrote:
> Could you please try to add the two following lines at the top of the
> 3 faulty files (types/session.h, types/proxy.h, types/protocols.h) :
>
> #include
> #include
>
> I think it should fix the build.
Thanks for your help. Unfortunately, it did not work. The errors are
exactly the same.
I noticed though, that the definition of sockaddr_storage in
/usr/include/sys/socket_impl.h looks like this:
#if !defined(_XPG4_2) || defined(_XPG6) || defined(__EXTENSIONS__)
[...]
struct sockaddr_storage {
sa_family_t ss_family; /* Address family */
/* Following fields are implementation specific */
char_ss_pad1[_SS_PAD1SIZE];
sockaddr_maxalign_t _ss_align;
char_ss_pad2[_SS_PAD2SIZE];
};
#endif
So if I add SILENT_DEFINE="-D__EXTENSIONS__=1" to the make call gcc does
not complain anymore (even without adding the additional includes). I'm
not currently able to decide if the resulting executable is completely
valid or if this is a valid approach even.
-Holger
Re: [ANNOUNCE] haproxy-1.4.0
Hi Holger, On Sat, Feb 27, 2010 at 01:28:12PM +0100, Holger Just wrote: > Hi all, > > On 2010-02-26 16:02, Willy Tarreau wrote: > > I'm obviously interested in any problem report :-) > > I'm trying to compile Haproxy 1.4 on Opensolaris Build 133 (i386 on a > Core i7). This however fails. thanks for your report. Could you please try to add the two following lines at the top of the 3 faulty files (types/session.h, types/proxy.h, types/protocols.h) : #include #include I think it should fix the build. Thanks! Willy
Re: [ANNOUNCE] haproxy-1.4.0
Hi all, On 2010-02-26 16:02, Willy Tarreau wrote: > I'm obviously interested in any problem report :-) I'm trying to compile Haproxy 1.4 on Opensolaris Build 133 (i386 on a Core i7). This however fails. make TARGET=solaris CPU=i686 USE_STATIC_PCRE=1 SMALL_OPTS="-I/usr/include/pcre" [...] gcc -Iinclude -Iebtree -Wall -O2 -march=i686 -g -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT -I/usr/include/pcre -DTPROXY -DENABLE_POLL -DUSE_PCRE -I/usr/include -DCONFIG_HAPROXY_VERSION=\"1.4.0\" -DCONFIG_HAPROXY_DATE=\"2010/02/26\" -c -o src/auth.o src/auth.c In file included from include/types/fd.h:32, from include/proto/fd.h:31, from include/common/standard.h:32, from include/common/compat.h:29, from include/types/acl.h:25, from include/proto/acl.h:26, from src/auth.c:22: include/types/protocols.h:87: error: field `addr' has incomplete type In file included from include/types/queue.h:29, from include/types/server.h:37, from include/types/lb_map.h:26, from include/types/backend.h:29, from include/types/proxy.h:40, from include/types/acl.h:30, from include/proto/acl.h:26, from src/auth.c:22: include/types/session.h:170: error: field `cli_addr' has incomplete type include/types/session.h:171: error: field `frt_addr' has incomplete type In file included from include/types/acl.h:30, from include/proto/acl.h:26, from src/auth.c:22: include/types/proxy.h:154: error: field `src' has incomplete type make: *** [src/auth.o] Error 1 I'm at an end here as my knowledge of C is rather sparse as is my (Open)solaris experience. --Holger
Re: [ANNOUNCE] haproxy-1.4.0
Willy Tarreau wrote: On Fri, Feb 26, 2010 at 03:57:16PM -0500, Jeff Buchbinder wrote: With that patch it does seem to build the files that were getting stuck before under OpenBSD 4.3. Excellent, thanks very much Jeff for your quick response, I'm applying the patch now. Much appreciated. Between that patch and the Makefile.bsd change, I think it's set to build "out of the box" on OpenBSD. -- Jeff Buchbinder Senior Infrastructure Engineer Rave Mobile Safety, Inc work: 508.848.2484 mobile: 860.617.5750 jbuchbin...@ravemobilesafety.com
Re: [ANNOUNCE] haproxy-1.4.0
On Fri, Feb 26, 2010 at 03:57:16PM -0500, Jeff Buchbinder wrote: > With that patch it does seem to build the files that were getting stuck > before under OpenBSD 4.3. Excellent, thanks very much Jeff for your quick response, I'm applying the patch now. Cheers, Willy
Re: [ANNOUNCE] haproxy-1.4.0
Willy Tarreau wrote: Could you please check if the following patch is enough to fix it ? I think it should in fact. Thanks, Willy diff --git a/include/common/compat.h b/include/common/compat.h index 3c939ce..9eecdfb 100644 --- a/include/common/compat.h +++ b/include/common/compat.h @@ -23,8 +23,8 @@ #define _COMMON_COMPAT_H /* This is needed on Linux for Netfilter includes */ -#include #include +#include #include #include With that patch it does seem to build the files that were getting stuck before under OpenBSD 4.3. -- Jeff Buchbinder Senior Infrastructure Engineer Rave Mobile Safety, Inc work: 508.848.2484 mobile: 860.617.5750 jbuchbin...@ravemobilesafety.com
Re: [ANNOUNCE] haproxy-1.4.0
On Fri, Feb 26, 2010 at 03:35:41PM -0500, Jeff Buchbinder wrote: > Willy Tarreau wrote: > >Thanks for your feedback, that helps a lot. Unfortunately I don't > >have any OpenBSD anymore here :-/ > > > No problem. > > About the error messages; it gives a bunch of error messages about > "/usr/include/sys/socket.h", complaining about syntax errors. Could you please check if the following patch is enough to fix it ? I think it should in fact. Thanks, Willy diff --git a/include/common/compat.h b/include/common/compat.h index 3c939ce..9eecdfb 100644 --- a/include/common/compat.h +++ b/include/common/compat.h @@ -23,8 +23,8 @@ #define _COMMON_COMPAT_H /* This is needed on Linux for Netfilter includes */ -#include #include +#include #include #include
Re: [ANNOUNCE] haproxy-1.4.0
On Fri, Feb 26, 2010 at 03:35:41PM -0500, Jeff Buchbinder wrote: > Willy Tarreau wrote: > >Thanks for your feedback, that helps a lot. Unfortunately I don't > >have any OpenBSD anymore here :-/ > > > No problem. > > About the error messages; it gives a bunch of error messages about > "/usr/include/sys/socket.h", complaining about syntax errors. OK, we had a similar one under linux recently due to sockaddr being added somewhere. Most likely one include is missing. > If you run it on an OpenBSD 4.x VM, you should see the same thing. Yes, obviously, but I just need to download it and install it :-) Thanks, Willy
Re: [ANNOUNCE] haproxy-1.4.0
Willy Tarreau wrote: Thanks for your feedback, that helps a lot. Unfortunately I don't have any OpenBSD anymore here :-/ No problem. About the error messages; it gives a bunch of error messages about "/usr/include/sys/socket.h", complaining about syntax errors. If you run it on an OpenBSD 4.x VM, you should see the same thing. -- Jeff Buchbinder Senior Infrastructure Engineer Rave Mobile Safety, Inc work: 508.848.2484 mobile: 860.617.5750 jbuchbin...@ravemobilesafety.com
Re: [ANNOUNCE] haproxy-1.4.0
On Fri, Feb 26, 2010 at 10:45:58AM -0500, Jeff Buchbinder wrote: > Willy Tarreau wrote: > >I'm obviously interested in any problem report :-) > > > One other OpenBSD build problem that I saw was that OBJS in Makefile.bsd > seems to be missing: > > src/auth.o src/stick_table.o src/pattern.o oops! indeed. I'll have to check if the osx makefile is up to date. > to build properly. Once those are back in the OBJS list (and the > previous fix has been made of commenting out the compat.h references), > haproxy does build successfully on OpenBSD 4.3 and 4.4. Thanks for your feedback, that helps a lot. Unfortunately I don't have any OpenBSD anymore here :-/ Willy
Re: [ANNOUNCE] haproxy-1.4.0
Hi Jeff, On Fri, Feb 26, 2010 at 10:38:55AM -0500, Jeff Buchbinder wrote: > Willy Tarreau wrote: > >I'm obviously interested in any problem report :-) > > > Build on OpenBSD 4.3 seems to fail unless "#include " > is commented out of the src/lb_*.c files. This seemed to be the case on > both the i386 and amd64 targets I was building on. could you please send me the output in case I can spot something obvious ? Thanks, Willy
Re: [ANNOUNCE] haproxy-1.4.0
Willy Tarreau wrote: I'm obviously interested in any problem report :-) One other OpenBSD build problem that I saw was that OBJS in Makefile.bsd seems to be missing: src/auth.o src/stick_table.o src/pattern.o to build properly. Once those are back in the OBJS list (and the previous fix has been made of commenting out the compat.h references), haproxy does build successfully on OpenBSD 4.3 and 4.4. -- Jeff Buchbinder Senior Infrastructure Engineer Rave Mobile Safety, Inc work: 508.848.2484 mobile: 860.617.5750 jbuchbin...@ravemobilesafety.com
Re: [ANNOUNCE] haproxy-1.4.0
Willy Tarreau wrote: I'm obviously interested in any problem report :-) Build on OpenBSD 4.3 seems to fail unless "#include " is commented out of the src/lb_*.c files. This seemed to be the case on both the i386 and amd64 targets I was building on. -- Jeff Buchbinder Senior Infrastructure Engineer Rave Mobile Safety, Inc jbuchbin...@ravemobilesafety.com
