www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples | github

Archive Index This month's Index

Subject: [libssh2] #273: build of libssh2-1.4.3 failed on Solaris 10 when specifying --with-libssl-prefix

[libssh2] #273: build of libssh2-1.4.3 failed on Solaris 10 when specifying --with-libssl-prefix

From: libssh2 Trac <trac_at_libssh2.stuge.se>
Date: Wed, 25 Sep 2013 11:58:53 -0000

#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
Received on 2013-09-25

the libssh2 team