#273: build of libssh2-1.4.3 failed on Solaris 10 when specifying --with-libssl-
prefix
-------------------------------+--------------------
Reporter: kdekker | Owner:
Type: defect | Status: new
Priority: normal | Milestone: 1.4.3
Component: misc | Version: 1.4.2
Keywords: configure failure | Blocked By:
Blocks: |
-------------------------------+--------------------
I'm working on SUSE SLES 11 SP3 x64 Linux with gcc 4.3.4.
When running configure:
{{{
./configure
--prefix=/vobs/obj.SUSE11/thirdparty/libssh2/32bit/libssh2-1.4.3/.. \
--without-libz --with-openssl \
--with-libssl-prefix=/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit
}}}
then configure failed to find libssl and openssl/ssl.h.
Trying to figure out the cause for this, I found that the include
directory was NOT added to the gcc command to build the test. This was
caused by missing propert -I and -L flags. The provided OpenSSL directory
exists for sure, but the logic to find the right values is incorrect.
Please read my findings below but I don't know a final solution or fix.
The config.log file showed:
{{{
configure:13896: checking for libssl
configure:13915: gcc -o conftest -m32 -march=pentium4 -mmmx -msse -msse2
\
-mfpmath=sse conftest.c -lssl -lcrypto >&5
conftest.c:25:25: error: openssl/ssl.h: No such file or directory
}}}
I also found that the alternate location was appended with lib64 for the
libraries. This location is at least
incorrect for 32-bit builds. The location is IMO incorrectly derived from:
gcc -print-search-dirs.
In my case, the output (see also configure on line 13413) was:
{{{
gcc -print-search-dirs | sed -n -e 's,^libraries: ,,p' | sed -e 's,^=,,'
/usr/lib64/gcc/x86_64-suse-linux/4.3/:/usr/lib/gcc/x86_64-suse-
linux/4.3/:/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-
linux/lib/x86_64-suse-linux/4.3/:/usr/lib64/gcc/x86_64-suse-
linux/4.3/../../../../x86_64-suse-
linux/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../x86_64
-suse-linux/4.3/:/usr/lib64/gcc/x86_64-suse-
linux/4.3/../../../../lib64/:/lib/x86_64-suse-
linux/4.3/:/lib/../lib64/:/usr/lib/x86_64-suse-
linux/4.3/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-
linux/4.3/../../../../x86_64-suse-linux/lib/:/usr/lib64/gcc/x86_64-suse-
linux/4.3/../../../:/lib/:/usr/lib/
}}}
but I was busy building 32-bit, so note the difference with the command
below:
{{{
gcc -m32 -print-search-dirs | sed -n -e 's,^libraries: ,,p' | sed -e
's,^=,,'
/usr/lib64/gcc/x86_64-suse-linux/4.3/32/:/usr/lib/gcc/x86_64-suse-
linux/4.3/32/:/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64
-suse-linux/lib/x86_64-suse-linux/4.3/32/:/usr/lib64/gcc/x86_64-suse-
linux/4.3/../../../../x86_64-suse-linux/lib/../lib/:/usr/lib64/gcc/x86_64
-suse-linux/4.3/../../../x86_64-suse-linux/4.3/32/:/usr/lib64/gcc/x86_64
-suse-linux/4.3/../../../../lib/:/lib/x86_64-suse-
linux/4.3/32/:/lib/../lib/:/usr/lib/x86_64-suse-
linux/4.3/32/:/usr/lib/../lib/:/usr/lib64/gcc/x86_64-suse-
linux/4.3/:/usr/lib/gcc/x86_64-suse-linux/4.3/:/usr/lib64/gcc/x86_64-suse-
linux/4.3/../../../../x86_64-suse-linux/lib/x86_64-suse-
linux/4.3/:/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-
linux/lib/:/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../x86_64-suse-
linux/4.3/:/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../:/lib/x86_64
-suse-linux/4.3/:/lib/:/usr/lib/x86_64-suse-linux/4.3/:/usr/lib/
}}}
In both cases the word 'lib64' was found, but when -m32 was specified,
directories are appended with "/32".
I would recommend to pass the compiler flags to gcc when performing this
test, i.e. configure:11290 and 13413 should be replaced from:
{{{
11290: lt_search_path_spec=`$CC -print-search-dirs | awk $lt_awk_arg |
$SED -e "s/^libraries://" -e $lt_sed_strip_eq`
13413: searchpath=`(LC_ALL=C $CC -print-search-dirs) 2>/dev/null | sed -n
-e 's,^libraries: ,,p' | sed -e 's,^=,,'`
}}}
to
{{{
11290: lt_search_path_spec=`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-search-
dirs | awk $lt_awk_arg | $SED -e "s/^libraries://" -e $lt_sed_strip_eq`
13413: searchpath=`(LC_ALL=C $CC $CPPFLAGS $CFLAGS $LDFLAGS -print-
search-dirs) 2>/dev/null | sed -n -e 's,^libraries: ,,p' | sed -e
's,^=,,'`
}}}
and the matches at lines congfigure:13419-13423 should be adjusted.
Based on the pattern 'lib64' (se configure:13419) acl_libdirstem is
incorrectly set to "lib64" causing troubles later at configure:13474.
Recent OpenSSL version never use lib64 suffix (but always lib). I'm not
100% sure, but older versions of OpenSSL may have used the lib64 naming
convention. I was now using openssl 1.0.1e.
You can probably replace the logic at lines 13:474 by some if -d tests,
and take $withval/lib or $withval/lib64 depending on which directory
exists, otherwise additional_libdir is still incorrect. A similar problem
exists in m4/lib-prefix.m4:49 where the call to gcc -print-search-dirs
need to be adjusted.
Anyhow, for 64-bits, OpenSSL uses 'lib' (at least for version 1.0.1e), so
using the output of gcc -print-search-dirs is IMO not related to how
openSSL creates the directory structure. Anotother detection method is
preferred to figure out which -L directory is needed (e.g. serveral test
-d "<sslprefix>/<libdir>" constructs). The compiler itself should be
clever enough to find it system libraries. So I even do not imagine in
which cases 'acl_libdirstem' is needed (of course, this is only true if an
alternate location for OpenSSL was provided).
Note that even if -m32 flag is specified, the directory
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../ (effective dir =
/usr/lib64) matches and (incorrectly) assigns acl_libdirstem=lib64 for
32-bit builds. So the proposed approach by passing $CFLAGS is insufficient
to find the right openSSL directory (if not installed, but taken from a
speficied path by using --with-libssl-prefix).
As soon as acl_libdirstem was fixed set (by me) to "lib" in all cases, the
additional_libdir was correct, both -L and -I were set and the example
compiled, but I then ran into other errors.
Another problem was reported: the test to discover whether the
'EVP_aes_128_ctr' symbol exists in libcrypto.a is probably incorrect.
configure output is:
checking for shared library run path origin... done
checking for libssl... yes
checking how to link with libssl...
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libssl.a
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a
'''checking for EVP_aes_128_ctr... no'''
checking whether to enable pedantic and debug compiler options... no
checking whether to enable hidden symbols in the library... no
checking whether to build example applications... yes
Config.log says:
{{{
configure:13126: gcc -c -m32 -march=pentium4 -mmmx -msse -msse2
-mfpmath=sse conftest.c >&5
configure:13126: $? = 0
configure:13134: result: 64
configure:13288: checking for ld used by GCC
configure:13352: result: /usr/x86_64-suse-linux/bin/ld -m elf_i386
configure:13359: checking if the linker (/usr/x86_64-suse-linux/bin/ld -m
elf_i386) is GNU ld
configure:13372: result: yes
configure:13379: checking for shared library run path origin
configure:13392: result: done
configure:13896: checking for libssl
configure:13915: gcc -o conftest -m32 -march=pentium4 -mmmx -msse -msse2
-mfpmath=sse -I/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/include
conftest.c /vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libssl.a
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a >&5
configure:13915: $? = 0
configure:13925: result: yes
configure:13932: checking how to link with libssl
configure:13934: result:
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libssl.a
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a
configure:14506: checking for EVP_aes_128_ctr
configure:14506: gcc -o conftest -m32 -march=pentium4 -mmmx -msse -msse2
-mfpmath=sse -I/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/include
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libssl.a
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a conftest.c >&5
/tmp/cc04CPfc.o: In function `main':
conftest.c:(.text+0x12): undefined reference to `EVP_aes_128_ctr'
collect2: ld returned 1 exit status
configure:14506: $? = 1
}}}
The source file that refers to that symbol need to be listed before the
archives are added. I.e. the following command should be changed from
{{{
gcc -o conftest -m32 -march=pentium4 -mmmx -msse -msse2 -mfpmath=sse
-I/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/include
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libssl.a
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a conftest.c >&5
}}}
to
{{{
gcc -o conftest conftest.c -m32 -march=pentium4 -mmmx -msse -msse2
-mfpmath=sse -I/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/include
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libssl.a
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a >&5
}}}
See also a small example:
{{{
cat kees.c
#include <stdio.h>
#include <openssl/ssl.h>
#include <openssl/evp.h>
int main(void)
{
SSL_library_init();
EVP_aes_128_ctr();
return 0;
}
gcc -m32 -o testkees -I/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/include
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libssl.a
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a kees.c
/tmp/ccmqHPlx.o: In function `main':
kees.c:(.text+0x12): undefined reference to `SSL_library_init'
kees.c:(.text+0x17): undefined reference to `EVP_aes_128_ctr'
collect2: ld returned 1 exit status
gcc -m32 -o testkees kees.c
-I/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/include
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libssl.a
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a(dso_dlfcn.o): In
function `dlfcn_globallookup':
dso_dlfcn.c:(.text+0x1b): undefined reference to `dlopen'
dso_dlfcn.c:(.text+0x33): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x3d): undefined reference to `dlclose'
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a(dso_dlfcn.o): In
function `dlfcn_pathbyaddr':
dso_dlfcn.c:(.text+0x72): undefined reference to `dladdr'
dso_dlfcn.c:(.text+0xc7): undefined reference to `dlerror'
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a(dso_dlfcn.o): In
function `dlfcn_bind_func':
dso_dlfcn.c:(.text+0x410): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x4e6): undefined reference to `dlerror'
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a(dso_dlfcn.o): In
function `dlfcn_bind_var':
dso_dlfcn.c:(.text+0x560): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x636): undefined reference to `dlerror'
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a(dso_dlfcn.o): In
function `dlfcn_unload':
dso_dlfcn.c:(.text+0x696): undefined reference to `dlclose'
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a(dso_dlfcn.o): In
function `dlfcn_load':
dso_dlfcn.c:(.text+0x75c): undefined reference to `dlopen'
dso_dlfcn.c:(.text+0x7c0): undefined reference to `dlclose'
dso_dlfcn.c:(.text+0x7fa): undefined reference to `dlerror'
collect2: ld returned 1 exit status
gcc -m32 -o testkees kees.c
-I/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/include
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libssl.a
/vobs/obj.SUSE11/thirdparty/OpenSSL/32bit/lib/libcrypto.a -ldl
}}}
The detection fails either due to the wrong library order, or due to
missing system libraries for dynamic loading shared libraries. I think the
ac_link command is incorrect and should put the conftest.$ac_ext before
$LD_FLAGS. I did not figure out why the test on 'checking for libssl' uses
the correct order of arguments, but the 'EVP_aes_128_ctr' check did not.
Sorry for the very long text. The information above may hopefully help you
in finding a solution. Feel free to ask me for figuring out more if
wanted. In case if you need testing on several platforms (we have AIX,
Solaris, Linux, HPUX, Windows) please let me know too.
--
Ticket URL: <https://trac.libssh2.org/ticket/273>
libssh2 <https://trac.libssh2.org/>
C library for writing portable SSH2 clients
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
