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