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 david@wood2.org.uk
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.in 28 May 2007 10:28:06 -0000 1.240 +++ configure.in 28 May 2007 10:46:54 -0000 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 -0000 1.35 +++ src/include/missing.h 25 May 2007 09:58:26 -0000 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
Hi Nicolas, In message <20070528110552.GC378@asuka.tech.sitadelle.com>, Nicolas Baradakis <nbk@sitadelle.com> 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=gethostbyname&apropos=0&sektion =3&manpath=FreeBSD+6.2-RELEASE&format=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 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. As this one doesn't involve autoconf, I could attempt to come up with a patch. I'm comfortable enough in C - it's autoconf that I lack experience with. However, I'd rather throw this back to the developers and let you come up with a solution that matches your design intent. If you let me have a patch, I'll keep on testing. As always, let me know if you want any more information. Best wishes, David -- David Wood david@wood2.org.uk
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
Hi Nicolas, In message <20070528205345.GA4224@asuka.tech.sitadelle.com>, Nicolas Baradakis <nbk@sitadelle.com> 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.
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.in Tue 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 fit the problem more accurately, as well as documenting why this special case is needed. It works correctly on my 6.2 box, but I don't have access to an older FreeBSD machine where the AC_TRY_COMPILE should fail. If an interim version of FreeBSD provides a defective gethostbyname_r() function, then there'd be some point in the behaviour after the patch in bug #454. I can't see that that's the case - gethostbyname_r() was introduced in CVS head, there were some changes, then - at least so far as the header goes - it was merged to RELENG_6 in one go, before the 6.2-RELEASE branch was made. I haven't bothered to check the history of the underlying code that provides that function. I don't follow FreeBSD 6-STABLE matters (6-STABLE which is what you get by tracking RELENG_6 at the moment) - but anyone still on 6.1-STABLE that hasn't upgraded to or beyond 6.2-RELEASE should probably expect some breakage. The same is true for anyone running 7-CURRENT; if something is broken, they should expect to update and rebuild. That's part of the cost of stepping away from -RELEASE versions close to the bleeding edge. In any case, even if there is a version of FreeBSD out there with a prototype for gethostbyname_r() but a defective implementation, then the 2.x will fail to build, just as 2.0.0-pre1 did prior to the patch in bug #454 (or the patch above). On to the next problem (and this time I can't see a Bugzilla report!). At least we're as far as installing now. Making install in include... gmake[4]: Entering directory `/var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0. 0-pre1/src/include' /var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0.0 -pre1/install-sh -c -d -m 755 /usr/local/include/freeradius /var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0.0 -pre1/install-sh -c -m 644 hash.h /usr/local/include/freera dius /var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0.0 -pre1/install-sh -c -m 644 libradius.h /usr/local/include/f reeradius /var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0.0 -pre1/install-sh -c -m 644 md4.h /usr/local/include/freerad ius /var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0.0 -pre1/install-sh -c -m 644 md5.h /usr/local/include/freerad ius /var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0.0 -pre1/install-sh -c -m 644 missing.h /usr/local/include/fre eradius /var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0.0 -pre1/install-sh -c -m 644 packet.h /usr/local/include/free radius /var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0.0 -pre1/install-sh -c -m 644 radius.h /usr/local/include/free radius /var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0.0 -pre1/install-sh -c -m 644 radpaths.h /usr/local/include/fr eeradius /var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0.0 -pre1/install-sh -c -m 644 sha1.h /usr/local/include/freera dius /var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0.0 -pre1/install-sh -c -m 644 token.h /usr/local/include/freer adius /var/ports/usr/ports_updated/net/freeradius2/work/freeradius-server-2.0.0 -pre1/install-sh -c -m 644 udpfromto.h /usr/local/include/f reeradius sed -i 's/^#include <freeradius-devel/#include <freeradius/' /usr/local/include/freeradius/libradius.h sed: 1: "/usr/local/include/free ...": extra characters at the end of l command gmake[4]: *** [install] Error 1 FreeBSD needs sed -i '' 's/...' - that is, you have to specify the null extension to -i with two ' signs. Can that simple change be made to src/include/Makefile in CVS (as I've already created a patch for in my port), or will that break sed on other OSes? At that point, all looks OK - except that I have some fixing to do in the package list, then I need to port my configuration to 2.x to test it. Best wishes, David -- David Wood david@wood2.org.uk
In message <dU4MLmNw+2WGFAB6@wood2.org.uk>, David Wood <david@wood2.org.uk> 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 david@wood2.org.uk
Hi Nicolas (and everyone), In message <W$J+RmS2F6WGFAjM@wood2.org.uk>, David Wood <david@wood2.org.uk> writes
In message <dU4MLmNw+2WGFAB6@wood2.org.uk>, David Wood <david@wood2.org.uk> 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.in Tue May 29 04:58:50 2007 +++ configure.in Tue 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 david@wood2.org.uk
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
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
participants (3)
-
Alan Dekok -
David Wood -
Nicolas Baradakis