Autotools related problems in freeradius 1.1.6

Kostas Zorbadelos kzorba at
Tue Apr 24 12:20:27 CEST 2007

On Mon, Apr 23, 2007 at 04:39:22PM +0200, Alan DeKok wrote:
> Kostas Zorbadelos wrote:
> > If I do 
> > 
> > ./configure --prefix=/opt/freeradius
> > 
> > the build scripts presume that --enable-developer is true.
>   That may be an issue only in 1.1.6.  You should be able to change it
> by doing --disable-developer.

This is exactly what I did. The reason I mention it is because I think
the default should be sane in future releases of freeradius (that is
developer options switched off by default).

> > This has
> > the effect that -DNDEBUG is not defined in CFLAGS during compilation,
> > among other things, so the rad_assert() function can abort freeradius
> > operation in production environments.
>   Which is not necessarily a bad thing.  Yes, it's bad for your RADIUS
> server to go down.  It's arguably worse for the RADIUS server to keep
> running, and doing... something... after it notices that internal sanity
> checks have failed.

I disagree with you on this one Alan. I discovered all these issues I
mention the hard way, after our radius server stopped running in
random times (after a failure in rad_assert() in request_list.c around
the section 

static int refresh_request(REQUEST *request, void *data)

	 *  If the request is marked as a delayed reject, AND it's
	 *  time to send the reject, then do so now.
	if (request->finished &&
	    ((request->options & RAD_REQUEST_OPTION_DELAYED_REJECT) != 0)) {
-------->	rad_assert(request->child_pid == NO_SUCH_CHILD_PID);

In production environments the server should be able to at least
report the errors it encounters and continue operations. Service
availability is the most important.

In our case, after I recompiled freeradius with -DNDEBUG option set,
we noticed no further noticable problems in our radius service.  

> > I believe that by default, --enable-developer should be false unless
> > explicitly set during configure. 
> > Let me know if you need anything else to trace the issue.
>   It's just a couple of lines of shell scripting in

As far as I can tell, the following minor patch should take care of the
issue of having developer flags switched off be default:

---   Tue Apr 24 12:02:13 2007
+++        Tue Apr 24 12:02:40 2007
@@ -278,11 +278,11 @@
 [  --enable-developer               Enables features of interest to developers.],
 [ case "$enableval" in
-    no)
-       developer=no
+    yes)
+       developer=yes
-       developer=yes
+       developer=no
   esac ]

> > Moreover, in a Solaris 9 environment
> > --enable-developer or --disable-developer seem to be ignored and
> > someone should define CFLAGS explicitly in the configure command to
> > define -NDEBUG macro.
> > 
I didn't manage to undestand however why in a Solaris environment,
--disable-developer seems to be ignored. Even if I set
--disable-developer in configure, the -DNDEBUG macro is not passed in
compilation options.
Find attached (a gzipped) BUILD log in my environment.


Kostas Zorbadelos

>   Alan DeKok.
> --
>       - The web site of the book
> - The blog
> - 
> List info/subscribe/unsubscribe? See
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BUILD.solaris-disable-developer.log.gz
Type: application/octet-stream
Size: 13495 bytes
Desc: not available
URL: <>

More information about the Freeradius-Users mailing list