Bug 168 - "Could not find working OpenSSL library"
Summary: "Could not find working OpenSSL library"
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: Build system (show other bugs)
Version: -current
Hardware: All All
: P1 minor
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
: 229 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-03-15 20:21 AEDT by d. l. taylor
Modified: 2004-04-14 12:24 AEST (History)
1 user (show)

See Also:


Attachments
configure.ac patch (ssl search cleanup) (5.33 KB, patch)
2002-04-28 01:50 AEST, Tim Rice
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description d. l. taylor 2002-03-15 20:21:24 AEDT
On Solaris 2.7 sparc, with OpenSSL installed in /usr/local/ssl, "configure
--with-ssl-dir=/usr/local/ssl" fails with error "Could not find working OpenSSL
library, please install or check config.log"

config.log contains:
------------------------------------------------------------------
configure:4605: gcc -o conftest -g -O2 -Wall  -I/usr/local/include -I/opt 
-L/usr/local/lib -R/usr/local/lib -L/opt -R/opt conftest.c -lz -lsocket -lnsl 
-lgen  -lcrypto 1>&5
configure:4594: openssl/rand.h: No such file or directory
configure: failed program was:
#line 4591 "configure"
#include "confdefs.h"

#include <string.h>
#include <openssl/rand.h>
------------------------------------------------------------------

The problem seems to result from this loop:
------------------------------------------------------------------
       for ssldir in $tryssldir "" /usr/local/openssl /usr/lib/openssl
/usr/local/ssl /usr/lib/ssl /usr/local /usr/pkg /opt /opt/openssl ; do
<snip>
                       # Try to use $ssldir/include if it exists, otherwise 
                        # $ssldir
                        if test -d "$ssldir/include" ; then
                                CPPFLAGS="$saved_CPPFLAGS -I$ssldir/include"
------------------------------------------------------------------

Since "saved_CPPFLAGS" (which is set to /usr/local/include) is never updated,
this loop merely appends the last existing directory (which is /opt on my
system) to CPPFLAGS.  Seems it should either append *all* existing include
directories from the "for" list", or only use the directory passed with the
"--with-ssl-dir" option.

An easy workaround is to remove all but "/usr/local/ssl" from the "for" list.
Comment 1 d. l. taylor 2002-03-15 20:25:46 AEDT
The openssh version is 2.5.2p2, but the relevant code in 3.1p1 "configure" looks
the same.
Comment 2 Damien Miller 2002-04-17 12:28:34 AEST
I don't understand the problem here: CPPFLAGS gets updated for each directory on
the list with either -Idirectory or -Idirectory/include (if it exists).
Comment 3 Damien Miller 2002-04-26 11:12:03 AEST
Can't replicate
Comment 4 d. l. taylor 2002-04-26 11:53:42 AEST
As I said, from the code (and the output) you can see each existing dir or
dir/include is not *appended* to CPPFLAGS, but *replaces* the previous.  So I
claim "configure --with-ssl-dir=/usr/local/ssl" works only in the following
cases:

1. OpenSSL headers are installed in /usr/local/include (or any one of the
directories CPPFLAGS is initially set to)and no directory in "for" list exists.

2. OpenSSL headers are installed in the last existing directory in "for" list

If my claim is incorrect, please explain and I apologize in advance.



Comment 5 Damien Miller 2002-04-26 16:00:26 AEST
You claim is incorrect: we break from the search loop if/when a test program
correctly executes. In this case, you are left with the correct directory in $ssldir

If the test program doesn't compile or execute then you get the error message.
Comment 6 Tim Rice 2002-04-28 01:44:00 AEST
*** Bug 229 has been marked as a duplicate of this bug. ***
Comment 7 Tim Rice 2002-04-28 01:50:40 AEST
Created attachment 89 [details]
configure.ac patch (ssl search cleanup)
Comment 8 Tim Rice 2002-04-28 01:54:58 AEST
Please test the patch in attachment (id=89)
We wre about to put this in a while back but it was right
before a release so we didn't. (Then we forgot about it) :-(
Comment 9 Ben Lindstrom 2002-11-10 03:50:45 AEDT
this patch was applied to 3.5.  If this issue still exists in 3.5 and above.  
Please reopen with new information.
Comment 10 Damien Miller 2004-04-14 12:24:18 AEST
Mass change of RESOLVED bugs to CLOSED