Some inconsistencies concerning OpenSSL include configuration in FRS 3

Dr. Andreas Rieke rieke at isl.de
Tue Jul 29 11:31:05 CEST 2014


Alan DeKok wrote:
> Dr. Andreas Rieke wrote:
>> I am quite sure that FRS compiles without problems on many other systems, but in those cases, the compiler takes the OpenSSL header files from the system and not from the specified directories - on my machine, I have removed the openssl-devel RPM package (CentOS), and thus, I get that failure. However, maybe the failure is better than a wrong header file...
>>
>> When I pass 'CPPFLAGS="-I /opt/openssl/include"' to the main configure script, the problems are solved for the headers - as an example, ec.h is found immediately. However, FRS still uses the system libraries :-(
>
>   The issue is that the CPPFLAGS are *supposed* to be passed from the
> main configure script to the lower-level ones.
>
>   Hmm... what happens if you edit the top-level "configure" script?
>
> - go to the bottom, and then look backwards for "werror"
>
> - you should see:
>
> if test "x$werror" == "xyes"; then
>   CFLAGS="-Werror $CFLAGS"
> fi
>
> - after that block, add:
>
> export CPPFLAGS CFLAGS LDFLAGS
>
> - then re-run configure
>
>   That should hopefully fix it.  If so, I'll commit a patch.
As promised, I have now tested your suggestion and I think that I now do understand your purpose. Sorry for the misunderstanding.

When you only pass the two parameters --with-openssl-include-dir=/opt/openssl/include und --with-openssl-lib-dir=/opt/openssl/lib to the main configure script (and no additional CPPFLAGS or LDFLAGS), all header files are found because with your modification "CPPFLAGS=    -isystem /opt/openssl/include/" is passed to the sub configure scripts. So far, so good.

However, I had expected that the library path is also passed to the sub scripts - and this is not the case, because there is no such parameter.

ldd shows that all rlms are linked to the correct version 1.0.0 of openssl, and not to the (old) system version which is 0.98 on my machine. For that reason, the result is correct, and 4 rlms make use of OpenSSL: libfreeradius-radius.so, rlm_cache.so, rlm_ldap.so and rlm_otp.so. As far as I can see, libfreeradius-radius, rlm_cache and rlm_otp have no own configure scripts, so let's take a closer look at rlm_ldap.

The configure script of rlm_ldap does receives the with-openssl-include-dir parameter, which it does not understand; however, it receives the header info from the environment:
> ac_cv_env_CPPFLAGS_value='    -isystem /opt/openssl/include/   '
I can not see anything about the library directory, but again, the result is correct.

Does this help? Can I test something else?

Best regards,

Andreas


More information about the Freeradius-Users mailing list