processing include files

Enrik Berkhan enrik#freeradius at planb.de
Mon Jul 9 09:24:12 CEST 2007


Alan DeKok schrieb:
>   I tried to build FreeRADIUS without pthread support.  I discovered at
> one point I couldn't do that *and* use SNMP, because the SNMP header
> files defined HAVE_PTHREAD_H.

That kind of problem actually has two causes:

1. The autoconf namespace pollution you mentioned. Avoid it where possible.

2. Misinterpretation of HAVE_FOO_H. IMHO, HAVE_FOO_H means, the header,
library, package, subsystem, whatever is _available_ on this system. It
shouldn't be used to decide if foo should be used or enabled when
building the software.

The first item can be actively adressed for FreeRADIUS by FreeRADIUS
itself. I think the solution for generated header files discussed
yesterday should be sufficient if it turns out to be actually working.

But when the first item is not obeyed by used libraries like netsmp, the
only solution is to make FreeRADIUS' autoconf setup more robust against
it by implementing the second item consistently. For pthreads, this
could look like:

- WITH_THREADS already exists in configure.in
- after pthread (or whatever threading solution might be supported in
the future ...) detection, set WITH_THREADS=pthreads, otherwise set it
to "no" or whatever
- AC_DEFINE(WITH_THREADS)
- make pthread code depend on #if WITH_THREADS == pthreads or something
similar instead of HAVE_PTHREAD_H

Of course, this should only exemplify how this could be done and
espacially the name "WITH_THREADS" should be chosen clever enough. Maybe
C-preprocessor symbols could even be avoided somehow.

After all, it should be possible to configure --with-threads=no then, no
matter if HAVE_PTHREADS_H is defined from anywhere.

Enrik



More information about the Freeradius-Devel mailing list