Description of problem: building distcache from src.rpm fails ssl.h usability test. Ran across this while building the dependencies for Apache 2.0.52 Version-Release number of selected component (if applicable): distcache-1.4.5-6.src.rpm How reproducible: Always Steps to Reproduce: It requires these dependencies: [root@LOCALHOST SRPMS]# rpm -q -p -R distcache-1.4.5-6.src.rpm automake >= 1.7 autoconf >= 2.50 libtool openssl-devel rpmlib(CompressedFileNames) <= 3.0.4-1 [root@LOCALHOST SRPMS]# We seem to have them: [root@LOCALHOST SRPMS]# rpm -q -a | grep "automake\|autoconf\|libtool\|openssl-devel" | sort autoconf213-2.13-9 autoconf-2.59-5 automake-1.9.2-3 libtool-1.4.3-6 libtool-libs-1.4.3-6 openssl-devel-0.9.7a-40 [root@LOCALHOST SRPMS]# Actual Results: But the build fails: [root@LOCALHOST SRPMS]# rpmbuild --rebuild distcache-1.4.5-6.src.rpm <MAJOR SNIPAGE> checking for strtol... yes checking for strdup... yes checking for SSL/TLS toolkit base... none checking openssl/opensslv.h usability... yes checking openssl/opensslv.h presence... yes checking for openssl/opensslv.h... yes checking openssl/ssl.h usability... no checking openssl/ssl.h presence... no checking for openssl/ssl.h... no configure: error: No SSL/TLS headers were available configure: error: /bin/sh './configure' failed for ssl error: Bad exit status from /var/tmp/rpm-tmp.8427 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.8427 (%build) [root@LOCALHOST SRPMS]# Expected Results: Successful build of distcache binary rpm. Additional info: Our ssl headers should have come from openssl-devel-0.9.7a-40.src.rpm which was built this morning, right before the distcache attempt. [root@LOCALHOST SRPMS]# [root@LOCALHOST SRPMS]# ls -l /usr/include/openssl/ssl.h -rw-r--r-- 1 root root 74482 Dec 15 09:40 /usr/include/openssl/ssl.h [root@LOCALHOST SRPMS]# THANKS!
Looking at /usr/src/redhat/BUILD/distcache-1.4.5/ssl/config.log it's choking on trying to include krb5.h from kssl.h I stole the krb5_prefix code from the openssh.spec and stuck it in. That seems to work nicely. here is the patch to distcache.spec --- distcache.spec 2004-08-31 15:16:21.000000000 -0400 +++ distcache.spec.new 2005-09-16 20:43:17.000000000 -0400 @@ -35,6 +35,16 @@ %patch0 -p1 -b .setuid %build +krb5_prefix=`krb5-config --prefix` +if test "$krb5_prefix" != "%{_prefix}" ; then + CPPFLAGS="$CPPFLAGS -I${krb5_prefix}/include -I${krb5_prefix}/include/gssapi"; export CPPFLAGS + CFLAGS="$CFLAGS -I${krb5_prefix}/include -I${krb5_prefix}/include/gssapi" + LDFLAGS="$LDFLAGS -L${krb5_prefix}/%{_lib}"; export LDFLAGS +else + krb5_prefix= + CPPFLAGS="-I%{_includedir}/gssapi"; export CPPFLAGS + CFLAGS="$CFLAGS -I%{_includedir}/gssapi" +fi libtoolize --force --copy && aclocal && autoconf automake -aic --gnu || : automake ate my hamster %configure --enable-shared
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
The information we've requested above is required in order to review this problem report further and diagnose/fix the issue if it is still present. Since there haven't been any updates to the report in quite a long time now after we've requested additional information, we're assuming the problem is either no longer present in our current OS release, or that there is no longer any interest in tracking the problem. Setting status to "INSUFFICIENT_DATA", however if you still experience this problem after updating to our latest Fedora release and are still interested in Red Hat tracking the issue, and assisting in troubleshooting the problem, please feel free to provide the information requested above, and reopen the report. Thank you in advance.