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