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.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 [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
