Re: 2.0.0-pre1 - cannot build on FreeBSD
David Wood wrote: It didn't take until tomorrow - this looks better, and is tested and apparently working with autoconf 2.61. Thanks for doing background research about the bug, and thanks for the patch. What do you think? Do you agree that that's a better solution than the patch in bug #454? I agree. It seems to be the underlying problem, so it's better to fix it like that. I've applied your patch to HEAD and branch 1.1. Meanwhile, I think I've fixed the packaging list for the FreeRADIUS 2 port on FreeBSD (and the script that generates it) - though this process did flag up one oddity. src/modules/rlm_eap/types/rlm_eap_psk is not built in 2.0.0-pre1. So far as I can tell, this is because Makefile.in is never turned into a Makefile. Is this intentional? I think this module is still experimental, therefore it's not surprising there is no Makefile and no configure script. -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 2.0.0-pre1 - cannot build on FreeBSD
David Wood wrote: Fortunately it's a two line change in the port's Makefile to delete configure after applying the patch and run configure.in through autoconf 2.61 - though if I don't need to do that, I don't, as it means that the port doesn't force systems without autoconf 2.61 to build and install autoconf. There's no need to do that. I just re-ran autoconf, and checked the results in. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 2.0.0-pre1 - cannot build on FreeBSD
David Wood wrote: I've put in quite a bit of work today towards porting 2.0.0-pre1 to FreeBSD, with the intention of submitting a FreeRADIUS 2 port as soon as possible. Unfortunately, there's a problem which I don't have the autoconf skills to patch quickly. When checking (and later attempting to use) net/if.h, you need to #include sys/socket.h on FreeBSD to get the definition of struct sockaddr. Thanks for the report. I hope the following changes in CVS head will solve the problem. (you also need to run autoconf) Index: configure.in === RCS file: /source/radiusd/configure.in,v retrieving revision 1.240 retrieving revision 1.241 diff -u -r1.240 -r1.241 --- configure.in28 May 2007 10:28:06 - 1.240 +++ configure.in28 May 2007 10:46:54 - 1.241 @@ -559,7 +559,6 @@ sys/security.h \ fcntl.h \ sys/fcntl.h \ - net/if.h \ prot.h \ pwd.h \ grp.h \ @@ -567,6 +566,13 @@ siad.h ) +dnl FreeBSD requires sys/socket.h before net/if.h +AC_CHECK_HEADERS(net/if.h, [], [], +[#if HAVE_SYS_SOCKET_H +# include sys/socket.h +# endif +]) + REGEX=no AC_CHECK_HEADER(regex.h, AC_DEFINE(HAVE_REGEX_H, [], [define this if we have the regex.h header file])) if test x$ac_cv_header_regex_h = xyes; then Index: src/include/missing.h === RCS file: /source/radiusd/src/include/missing.h,v retrieving revision 1.35 retrieving revision 1.36 diff -u -r1.35 -r1.36 --- src/include/missing.h 25 May 2007 09:57:15 - 1.35 +++ src/include/missing.h 25 May 2007 09:58:26 - 1.36 @@ -50,6 +50,10 @@ #include sys/select.h #endif +#ifdef HAVE_SYS_SOCKET_H +#include sys/socket.h +#endif + #ifdef HAVE_UNISTD_H #include unistd.h #endif -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 2.0.0-pre1 - cannot build on FreeBSD
Hi Nicolas, In message [EMAIL PROTECTED], Nicolas Baradakis [EMAIL PROTECTED] writes David Wood wrote: I've put in quite a bit of work today towards porting 2.0.0-pre1 to FreeBSD, with the intention of submitting a FreeRADIUS 2 port as soon as possible. Unfortunately, there's a problem which I don't have the autoconf skills to patch quickly. When checking (and later attempting to use) net/if.h, you need to #include sys/socket.h on FreeBSD to get the definition of struct sockaddr. Thanks for the report. I hope the following changes in CVS head will solve the problem. (you also need to run autoconf) That solves that problem - thanks. As you've committed that to the CVS head, the chances are that that problem is fixed for good - and it may help out on other BSD and BSD like operating systems. Fortunately it's a two line change in the port's Makefile to delete configure after applying the patch and run configure.in through autoconf 2.61 - though if I don't need to do that, I don't, as it means that the port doesn't force systems without autoconf 2.61 to build and install autoconf. That said, there's a problem in the 1.x port that I want to fix in 2.x (and eventually backport to 1.x) which will require me to patch configure.in - so I'll probably finish up depending on autoconf anyway. Back to 2.0.0-pre1. Fixing that problem reveals another problem - src/lib/getaddrinfo.c (a new file in 2.x) attempts to redefine gethostbyaddr_r(): /usr/local/bin/libtool --mode=compile cc -O -pipe -march=pentium3 -I/usr/local/include -L/usr/local/lib -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -D_LIBRADIUS -I/var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0 .0-p re1/src -c getaddrinfo.c cc -O -pipe -march=pentium3 -I/usr/local/include -L/usr/local/lib -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -D_LIBRADIUS -I/var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0 .0-pre1/src -c getaddrinfo.c -fPIC -DPIC -o .libs/getaddrinfo.o getaddrinfo.c:159: error: conflicting types for 'gethostbyaddr_r' /usr/include/netdb.h:225: error: previous declaration of 'gethostbyaddr_r' was here getaddrinfo.c:159: error: conflicting types for 'gethostbyaddr_r' /usr/include/netdb.h:225: error: previous declaration of 'gethostbyaddr_r' was here getaddrinfo.c:26: warning: 'lrad_hostbyname' defined but not used getaddrinfo.c:28: warning: 'lrad_hostbyname_mutex' defined but not used getaddrinfo.c:159: warning: 'gethostbyaddr_r' defined but not used gmake[4]: *** [getaddrinfo.lo] Error 1 There's a comment in configure.in, at line 900 (after applying your patch), about Tru64 having a BSD style function gethostbyaddr_r() function that's thread safe. The same is true of FreeBSD now - the BSD style gethostbyaddr_r() function is thread safe on FreeBSD since at least FreeBSD 4.11. FreeBSD 4.x is now end of life, and the only supported versions of FreeBSD are 5.x and 6.x - with 7.x under development, so that means all supported (and even some legacy) versions of FreeBSD have a thread safe (but three argument BSD style) function built in. The FreeBSD ports system has dropped support for 4.x, but I haven't removed the 4.x specific stuff from the FreeRADIUS 1.x port. I'm not going to support 4.x on FreeRADIUS 2.x, however - I would be very unlikely to get any new port with 4.x support committed now. http://www.freebsd.org/cgi/man.cgi?query=gethostbynameapropos=0sektion =3manpath=FreeBSD+6.2-RELEASEformat=html is the reference to the appropriate man page - see the second paragraph under BUGS for the reference to thread safety. The prototype for gethostbyaddr_r is included via #include netdb.h, which configure is picking up as available on FreeBSD. That's the same header as the C compiler is flagging up in the errors. I suspect this problem will affect all other systems which finish up the configure run with #define GETHOSTBYADDRRSTYLE BSDSTYLE in confdefs.h and that also have a prototype for the built-in gethostbyaddr_r() netdb.h (or another header file that FreeRADIUS finishes up #including). The logic in src/lib/getaddrinfo.c makes this attempted redefinition near certain on many BSD and BSD-like systems: #undef LOCAL_GETHOSTBYADDRR #ifndef GETHOSTBYADDRRSTYLE #define LOCAL_GETHOSTBYADDRR 1 #elif (GETHOSTBYADDRRSTYLE != SYSVSTYLE) (GETHOSTBYADDRRSTYLE != GNUSTYLE) #define LOCAL_GETHOSTBYADDRR 1 #endif /* GETHOSTBYADDRRSTYLE */ If GETHOSTBYADDRRSTYLE is BSDSTYLE, LOCAL_GETHOSTBYADDRR is #defined to 1, which means the block of code around line 180 that begins #ifdef LOCAL_GETHOSTBYADDRR will be compiled, attempting to redefine gethostbyaddr_r(). However, if GETHOSTBYADDRRSTYLE is BSDSTYLE rather than not defined, the chances are that you've already #included the header that contains the prototype for the system gethostbyaddr_r(). As an aside, FreeBSD 6.2-RELEASE-p4 i386, which is the OS on my
Re: 2.0.0-pre1 - cannot build on FreeBSD
David Wood wrote: As an aside, FreeBSD 6.2-RELEASE-p4 i386, which is the OS on my development box, finishes up with #define GETHOSTBYNAMERSTYLE GNUSTYLE in confdefs.h - so there won't be a similar problem with redefining gethostbyname_r on FreeBSD - but there may be on other operating systems. This should be fixed in CVS, but unfortunately after the release of 2.0.0-pre1. I think the problem you describe is the same as bug #454 in the bugzilla. http://bugs.freeradius.org/show_bug.cgi?id=454 -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 2.0.0-pre1 - cannot build on FreeBSD
Hi Nicolas, In message [EMAIL PROTECTED], Nicolas Baradakis [EMAIL PROTECTED] writes David Wood wrote: As an aside, FreeBSD 6.2-RELEASE-p4 i386, which is the OS on my development box, finishes up with #define GETHOSTBYNAMERSTYLE GNUSTYLE in confdefs.h - so there won't be a similar problem with redefining gethostbyname_r on FreeBSD - but there may be on other operating systems. This should be fixed in CVS, but unfortunately after the release of 2.0.0-pre1. I think the problem you describe is the same as bug #454 in the bugzilla. http://bugs.freeradius.org/show_bug.cgi?id=454 Thanks for the quick reply. That's a solution - but there's still arguably an underlying problem left here. The reporter of bug #454 is quite correct - FreeBSD 6.2 has gethostbyname_r() prototype and the corresponding code exists, whilst earlier versions of FreeBSD didn't have gethostbyname_r() (see http://www.freebsd.org/cgi/cvsweb.cgi/src/include/netdb.h#rev1.41 for the change in HEAD and http://www.freebsd.org/cgi/cvsweb.cgi/src/include/netdb.h#rev1.38.2.2 for the change on RELENG_6). The underlying problem that remains unfixed in 2.x following the patch in bug #454 is that if GETHOSTBYNAMERSTYLE is BSDSTYLE but there is already a definition of gethostbyname_r() in the headers that are being included by src/lib/getaddrinfo.c, you'll finish up with a compile error because of the attempt to redefine gethostbyname_r(). As the current state of configure.in means that this scenario is only likely on FreeBSD 6.2 and upwards and the patch in bug #454 deals with that problem, you can argue that the bug is closed and that's it. However, I looked deeper into why the special case in the section of configure.in dealing with GETHOSTBYNAMERSTYLE for FreeBSD arose in the first place. Checking back on the FreeRADIUS CVS server shows that this special case for FreeBSD in configure.in arose from a commit with the following log message: revision 1.188 date: 2003/10/13 12:12:28; author: phampson; state: Exp; lines: +11 -3 Override GETHOSTBYADDRSTYLE for FreeBSD to be BSD, to avoid stub GNU-style gethostbyaddr_r being linked in during configure, but not during build. That relates to the thread on freeradius-users that started with http://lists.cistron.nl/pipermail/freeradius-users/2003-October/024165.h tml. My understanding based on that thread is that at some point early in the FreeBSD 5 line, there was a gethostbyname_r() symbol to link against, but no corresponding prototype. Whether gethostbyname_r() worked if you called it, I have no idea; FreeBSD 5.0 / 5.1 is pretty ancient now and long since unsupported. The mention of gethostbyaddr_r as a stub and the fact that it took until 6.2 for this to be available suggests that it didn't work in 5.1. FreeBSD 5.5 is the latest and almost certainly the last release from the 5.x line - most people have migrated now to 6.x, and many skipped 5.x completely for reasons that don't matter here. FreeRADIUS 1.1.6 compiles just fine on FreeBSD 6.2-RELEASE - even though GETHOSTBYADDRRSTYLE is forced to BSDSTYLE on FreeBSD and there is a usable gethostbyaddr_r() function. However, FreeRADIUS 1.1.6 doesn't attempt to provide its own gethostbyaddr_r() function - instead, it uses the BSD style gethostbyaddr(), which on FreeBSD 4.11 and upwards (if not before) is thankfully thread safe. At the very least, I would argue that the patch in bug #454 should be applied to the 1.1 branch - if FreeBSD 6.2-RELEASE has a working gethostbyaddr_r() function, shouldn't FreeRADIUS 1.1.x be using it? For future robustness, rather than a version number check (it's just possible that FreeBSD 5.x will get a working gethostbyaddr_r(), much as I doubt it), here's an alternative patch to that in bug #454, using http://lists.cistron.nl/pipermail/freeradius-users/2003-October/024297.html as my inspiration: --- configure.in Mon May 28 19:46:57 2007 +++ configure.inTue May 29 00:17:43 2007 @@ -904,9 +904,21 @@ AC_MSG_CHECKING([gethostbyaddr_r() syntax]) case $host in *-freebsd*) +dnl With FreeBSD, check if there's a GNU style prototype for gethostbyaddr_r. +dnl Some versions (FreeBSD 5.1?) have a symbol but no prototype - so we override this test to +dnl BSDSTYLE. FreeBSD 6.2 and up have proper GNU style support. + freebsdmissingprototype=yes + AC_TRY_COMPILE([ +#include stdio.h +#include netdb.h +], [ gethostbyaddr_r(NULL, 0, 0, NULL, NULL, 0, NULL, NULL) ], [ + freebsdmissingprototype=no +]) +if test $freebsdmissingprototype = yes; then AC_DEFINE(GETHOSTBYADDRRSTYLE, BSDSTYLE, [style of gethostbyaddr_r functions ]) gethostbyaddrrstyle=BSD AC_MSG_WARN([FreeBSD overridden to BSD-style]) +fi ;; esac if test x$gethostbyaddrrstyle = x; then (with apologies that my mailer will mangle the tabs and possibly the line wraps - it's a good mailer but hopeless for patches). To my mind, that seems to
Re: 2.0.0-pre1 - cannot build on FreeBSD
In message [EMAIL PROTECTED], David Wood [EMAIL PROTECTED] writes For future robustness, rather than a version number check (it's just possible that FreeBSD 5.x will get a working gethostbyaddr_r(), much as I doubt it), here's an alternative patch to that in bug #454, using http://lists.cistron.nl/pipermail/freeradius-users/2003-October/024297.html as my inspiration: Not only is that patch ugly - further testing proves that it's flawed. I'll have another go at it tomorrow. David -- David Wood [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 2.0.0-pre1 - cannot build on FreeBSD
Hi Nicolas (and everyone), In message [EMAIL PROTECTED], David Wood [EMAIL PROTECTED] writes In message [EMAIL PROTECTED], David Wood [EMAIL PROTECTED] writes For future robustness, rather than a version number check (it's just possible that FreeBSD 5.x will get a working gethostbyaddr_r(), much as I doubt it), here's an alternative patch to that in bug #454, using http://lists.cistron.nl/pipermail/freeradius-users/2003-October/024297.html as my inspiration: Not only is that patch ugly - further testing proves that it's flawed. I'll have another go at it tomorrow. It didn't take until tomorrow - this looks better, and is tested and apparently working with autoconf 2.61. Note - this patch is against 2.0.0-pre1, not CVS HEAD. --- BEGIN --- --- configure.inTue May 29 04:58:50 2007 +++ configure.inTue May 29 04:57:03 2007 @@ -904,9 +904,17 @@ AC_MSG_CHECKING([gethostbyaddr_r() syntax]) case $host in *-freebsd*) - AC_DEFINE(GETHOSTBYADDRRSTYLE, BSDSTYLE, [style of gethostbyaddr_r functions ]) - gethostbyaddrrstyle=BSD - AC_MSG_WARN([FreeBSD overridden to BSD-style]) +dnl With FreeBSD, check if there's a prototype for gethostbyaddr_r. +dnl Some versions (FreeBSD 5.1?) have a symbol but no prototype - so we override this test to +dnl BSDSTYLE. FreeBSD 6.2 and up have proper GNU style support. + AC_CHECK_DECLS([gethostbyaddr_r], [], [ + AC_DEFINE(GETHOSTBYADDRRSTYLE, BSDSTYLE, [style of gethostbyaddr_r functions ]) + gethostbyaddrrstyle=BSD + AC_MSG_WARN([FreeBSD overridden to BSD-style]) + ], [ +#include stdio.h +#include netdb.h +]) ;; esac if test x$gethostbyaddrrstyle = x; then --- END --- (with apologies once again about the lost tabs - a plain/text MIME attachment might keep them, but cut and paste means a tab is turned into 8 spaces in my mailer) As a check on functionality, I temporarily changed the name of the function in the first parameter of AC_CHECK_DECLS to garbage, which changed the behaviour of the code as I'd intended (verified by diffing config.log between the 'garbage'' and normal runs). What do you think? Do you agree that that's a better solution than the patch in bug #454? Meanwhile, I think I've fixed the packaging list for the FreeRADIUS 2 port on FreeBSD (and the script that generates it) - though this process did flag up one oddity. src/modules/rlm_eap/types/rlm_eap_psk is not built in 2.0.0-pre1. So far as I can tell, this is because Makefile.in is never turned into a Makefile. Is this intentional? I'll continue to test as I find the time over the next few days - I need to port my configuration to FreeRADIUS 2.x, as well as check my port carefully. Best wishes, David -- David Wood [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
2.0.0-pre1 - cannot build on FreeBSD
Dear all, I've put in quite a bit of work today towards porting 2.0.0-pre1 to FreeBSD, with the intention of submitting a FreeRADIUS 2 port as soon as possible. Unfortunately, there's a problem which I don't have the autoconf skills to patch quickly. When checking (and later attempting to use) net/if.h, you need to #include sys/socket.h on FreeBSD to get the definition of struct sockaddr. If someone can give me a patch, I'll carry on with the work. What actually happens is that configure complains: configure: WARNING: net/if.h: present but cannot be compiled configure: WARNING: net/if.h: check for missing prerequisite headers? configure: WARNING: net/if.h: see the Autoconf documentation configure: WARNING: net/if.h: section Present But Cannot Be Compiled configure: WARNING: net/if.h: proceeding with the preprocessor's result configure: WARNING: net/if.h: in the future, the compiler will take precedence with the underlying entry in config.log of: configure:22662: checking net/if.h usability configure:22679: cc -c -O -pipe -march=pentium3 -I/usr/local/include -L/usr/local/lib -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS conft est.c 5 In file included from conftest.c:83: /usr/include/net/if.h:265: error: field `ifru_addr' has incomplete type /usr/include/net/if.h:266: error: field `ifru_dstaddr' has incomplete type /usr/include/net/if.h:267: error: field `ifru_broadaddr' has incomplete type /usr/include/net/if.h:299: error: field `ifra_addr' has incomplete type /usr/include/net/if.h:300: error: field `ifra_broadaddr' has incomplete type /usr/include/net/if.h:301: error: field `ifra_mask' has incomplete type /usr/include/net/if.h:368: error: field `addr' has incomplete type /usr/include/net/if.h:369: error: field `dstaddr' has incomplete type (the incomplete type is no definition of struct sockaddr). If you let things continue, the build eventually fails thus: /usr/local/bin/libtool --mode=compile cc -O -pipe -march=pentium3 -I/usr/local/include -L/usr/local/lib -D_REENTRANT -D_POSIX_PTHRE AD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -D_LIBRADIUS -I/var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0 .0-p re1/src -c misc.c cc -O -pipe -march=pentium3 -I/usr/local/include -L/usr/local/lib -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDE BUG -D_LIBRADIUS -I/var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0 .0-pre1/src -c misc.c -fPIC -DPIC -o .lib s/misc.o misc.c: In function `ip_hton': misc.c:424: error: `AF_INET' undeclared (first use in this function) misc.c:424: error: (Each undeclared identifier is reported only once misc.c:424: error: for each function it appears in.) misc.c: In function `ip_ntoh': misc.c:455: error: storage size of 'ss' isn't known misc.c:469: error: `AF_INET' undeclared (first use in this function) misc.c:455: warning: unused variable `ss' misc.c: In function `lrad_ipaddr_cmp': misc.c:585: error: `AF_INET' undeclared (first use in this function) gmake[4]: *** [misc.lo] Error 1 (sys/socket.h contains the #define for AF_INET - so if it's not the same problem, it's a very similar one). If anyone wants more information (logs, typescript), I'll happily provide them. I also can't get the PGP signature on the 2.0.0-pre1 tarball to verify - in the fairly old version of PGP 7 on my Windows XP box (which is the only place I have my keyrings), I get a bad signature error. The signature on 1.1.6 works just fine. Looking forward to 2.0 - and trusting this is useful, David -- David Wood [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
