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