2.0.0-pre1 - cannot build on FreeBSD

David Wood david at wood2.org.uk
Tue May 29 02:11:28 CEST 2007


Hi Nicolas,

In message <20070528205345.GA4224 at asuka.tech.sitadelle.com>, Nicolas 
Baradakis <nbk at 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.
>
>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
david at wood2.org.uk



More information about the Freeradius-Users mailing list