compile issues with freeradius 1.0.5 on solaris 10

[Garrett.Marks at wichita.edu]

Hello,

I was having problems compiling freeradius-1.0.5 on Solaris 10 (sparc) 
that were rather difficult to troubleshoot.  I managed to get the 
compilation completed successfully, but it seems that maybe there could be 
some changes to improve the experience others have with compiling 
freeradius on Solaris 10 in the future.

The problem I had, and another poster had, centers around configuring 
freeradius to compile with openssl. The full set of configure options I 
used were as follows:

./configure \
        --prefix=/usr/local/freeradius \
        --with-threads \
        --with-ldap \
        --with-openssl-includes=/usr/sfw/include/openssl \
        --with-openssl-libraries=/usr/sfw/lib \
        --with-rlm-ldap-include-dir=/usr/local/openldap/include \
        --with-rlm-ldap-lib-dir=/usr/local/openldap/lib \

With no changes to my environment I get the following error:
....
gcc  -L../lib -o radwho radwho.o util.o log.o conffile.o -L/usr/sfw/lib 
-lssl -L/usr/sfw/lib -lcrypto -lnsl -lresolv -lsocket -lposix4  -lpthread 
-lradius  -lcrypt
Undefined                       first referenced
 symbol                             in file
MD5Init                             ../lib/libradius.a(radius.o)  (symbol 
belongs to implicit dependency /usr/lib/libmd5.so.1)
MD5Final                            ../lib/libradius.a(radius.o)  (symbol 
belongs to implicit dependency /usr/lib/libmd5.so.1)
MD5Update                           ../lib/libradius.a(radius.o)  (symbol 
belongs to implicit dependency /usr/lib/libmd5.so.1)
ld: fatal: Symbol referencing errors. No output written to radwho
...

The error does not occur when I run the configure from above leaving out 
the two openssl options.
This was fixed by adding the following to my environment:
LIBS=-lmd5
export LIBS
* - This issue and workaround was mentioned by a previous poster.

Should md5 be added to the list of libraries automatically defined during 
the configure process for the above?


Then I get the following error:
...
gcc  -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -DOPENSSL_NO_KRB5 
-I/usr/sfw/include/openssl -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith 
-Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W 
-Wredundant-decls -Wundef  -I../include  -DHOSTINFO=\"\" 
-DRADIUSD_VERSION=\"1.0.5\"   -c radclient.c
radclient.c: In function `main':
radclient.c:788: error: `RADIUS_DICTIONARY' undeclared (first use in this 
function)
radclient.c:788: error: (Each undeclared identifier is reported only once
radclient.c:788: error: for each function it appears in.)
gmake[4]: *** [radclient.o] Error 1
gmake[4]: Leaving directory `/tmp/freeradius-1.0.5/src/main'
...

This was a rather perplexing error as upon investigation of the 
radclient.c source and the freeradius-1.0.5/src/include directory, 
RADIUS_DICTIONARY is defined in ../include/conf.h and radclient.c has an 
include statement for conf.h.  It is even more perplexing when 
investigating the gcc command from above, clearly the conf.h should be 
findable through the "-I../include" portion of the command.  Following a 
suggestion, I set my CFLAGS env variable to CFLAGS="-I../include 
-I/usr/local/openldap/include" to force the -I../include to appear further 
up in the gcc command.  To my surprise that allowed the compilation to 
finish successfully. 

After further investigation we discovered that there is also a "conf.h" 
file in the /usr/sfw/include/openssl directory which appears before the 
-I../include in the gcc command formed above.  Therefore the radclient.c 
sees the openssl conf.h which does not have the `RADIUS_DICTIONARY' 
defined, thus the error.  I checked the openssl source not from Sun and 
they have a "conf.h" as well.

I could imagine a couple of possible fixes for this issue:
1) Modify configure to place the -I/usr/sfw/include/openssl  (the ssl 
include path) to be after the -I../include?
or
2) Change the name of conf.h to something more descriptive and specific to 
freeradius to avoid conflicts like this?

Another interesting aspect is that with 1.0.4, it seems as if the 
--with-openssl-lib= option wasn't really working, because even with that 
set it wouldn't find ssl or libcrypt unless I set LD_LIBRARY_PATH.  Now 
with 1.0.5 I don't have to set LD_LIBRARY_PATH.

-Garrett Marks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20051108/d7edfedc/attachment.html>