Bugs item #3029420, was opened at 2010-07-14 11:46
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3029420&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: compile or build problem
Group: None
Status: Open
Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: kdekker (kdekker)
Assigned to: Daniel Stenberg (bagder)
Summary: clash with 64-bit build and openssl1.0.0a

Initial Comment:
For some reason, open SSL changed their output directories for soe 64-bit builds.
If prefix is x (used during configure of openSSL), the static libraries (.a files) and pkgconfig subdirectory are put in:
Solaris: x/lib/66
HPUX IA64: x/lib/hpux64
HPUX PA-risc; x/lib/pa20_64
Linux: x/lib64

Although these namings are similar to how the involved OS put their system libs under /lib, cURL configure can't handle this. Also, if -Lx/lib was specified during linking/compilation, the compiler/linker was not able to find e.g. libssl.a or libcrypto.a.

The cURL configure output points already to an error/warning:
checking if GSSAPI support is requested... no
configure: PKG_CONFIG_LIBDIR will be set to "/vobs/obj.SOL10/thirdparty/OpenSSL/64bit/lib/pkgconfig"
checking for CRYPTO_lock in -lcrypto... no
checking for CRYPTO_add_lock in -lcrypto... no
configure: WARNING: zlib disabled
configure: WARNING: SSL disabled, you will not be able to use HTTPS, FTPS, NTLM and more.
configure: WARNING: Use --with-ssl, --with-gnutls, --with-polarssl or --with-nss to address this.
checking default CA cert bundle/path... no

I understand why openSSL changes the output directory (espcially of you need both 32 and 64 bit SSL together in one /usr/local/ssl directory), however, I don't know whether cURL should be able to handle this.

Unfortunatelly, I don't have pkg-config on a lot of systems. Either specifying PKG_CONFIG_PATH or --with-ssl=PATH does not work. In case if I specify --with-ssl=x/lib/64, then the include files are not found (which are still in x/include). If you know a workaround for this problem, it would be great.

Feel free to ask for more information, if needed.

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2010-07-16 10:49

Message:
Does this mean you can make it work now for Linux too?

----------------------------------------------------------------------

Comment By: kdekker (kdekker)
Date: 2010-07-16 09:13

Message:
Mea culpa. I provided the from LDFLAGS. Sorry.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-07-15 19:24

Message:
Your config.log reveals that you need to provide -ldl for the OpenSSL link
tests to succeed. Pass that flag with "LDFLAGS=-ldl"

----------------------------------------------------------------------

Comment By: kdekker (kdekker)
Date: 2010-07-15 16:23

Message:
I also opened a ticket with the openSSL guys:
http://rt.openssl.org/Ticket/Display.html?id=2307&user=guest&pass=guest

----------------------------------------------------------------------

Comment By: kdekker (kdekker)
Date: 2010-07-15 16:19

Message:
Just my 2 cents: pkg-config is (at default?) available on Linux, but due to
the provided --with-ssl=<dir> flag, the requird pkgconfig subdir is not
found. The directory <dir> is the parent directory of include, but not of
lib. The openSSL archive is in <dir>/lib64. See below for directory tree. I
also attached config.log.

vobs/obj.SUSE10/thirdparty/OpenSSL/64bit
/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/openssl-1.0.0a
...
/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/openssl-1.0.0a/VMS
/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/bin
/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/lib64
/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/lib64/engines
/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/lib64/pkgconfig
/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/include
/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/include/openssl
/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/ssl
/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/ssl/misc
/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/ssl/certs
/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/ssl/private

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-07-15 13:58

Message:
Most likely you're just not using it right then. You should check
config.log after the failure to get some clues on exactly which check that
fails and how.

The configure output seems to imply that configure found a pkg-config, but
that the contents of that is wrong as it didn't find any lib when
testing...

----------------------------------------------------------------------

Comment By: kdekker (kdekker)
Date: 2010-07-15 12:09

Message:
HPUX PA-risc and AIX did work as well (64-bit builds). So still Linux is
(for me) the only one not working.

----------------------------------------------------------------------

Comment By: kdekker (kdekker)
Date: 2010-07-15 11:44

Message:
The trick did not work on Linux. I got:

checking for monotonic clock_gettime... yes
checking for clock_gettime in libraries... -lrt
checking if monotonic clock_gettime works... yes
checking whether to use libgcc... no
checking whether to enable ipv6... yes
checking if struct sockaddr_in6 has sin6_scope_id member... yes
checking if argv can be written to... yes
checking if Kerberos4 support is requested... no
checking if SPNEGO support is requested... no
checking if GSSAPI support is requested... no
configure: PKG_CONFIG_LIBDIR will be set to
"/vobs/obj.SUSE10/thirdparty/OpenSSL/64bit/lib/pkgconfig"
checking for CRYPTO_lock in -lcrypto... yes
checking for SSL_connect in -lssl... no
checking for ssl with RSAglue/rsaref libs in use... checking for
SSL_connect in -lssl... (cached) no
no
configure: error: OpenSSL libs and/or directories were not found where
specified!
*** Error code 1 (ignored)

but did not (yet) figure out why. May be the OS-installed libssl is the
cause, I don't know. The trick worked for HPIA64 and for Solaris.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-07-14 22:59

Message:
That doesn't make sense! We have the exact same configure script with the
exact same tests for all these platforms, so why would a trick that works
on one platform not work on another?

----------------------------------------------------------------------

Comment By: kdekker (kdekker)
Date: 2010-07-14 16:59

Message:
Correction: it worked for solaris, but not for Linux. I will check HPUX
(IA64 as well as PA-risc 64-bit too). If I find the openssl new 64-bit libn
structure so annoying, I may consider filing a dect :-(

----------------------------------------------------------------------

Comment By: kdekker (kdekker)
Date: 2010-07-14 16:12

Message:
I added -L specialized per (64-bit) platform, by passing LDFLAGS=-Lx
./configure when configuring cURL. That helped. I agree that the changes in
openSSL are weird. This ticket can be closed then.

I assume that the OpenSSL guys will not roll-back this change, but it may
be worth to spend some words in the docs/INSTALL about openssl1.0.0a and
64-bit (Unix).

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-07-14 16:07

Message:
That's just so insane I want to cry. I would advice that you instead build
and install OpenSSL to use a sane and fixed "include" and "lib" setup.

You can still make curl find OpenSSL even in that weirdo setup, if you
just pass on environment variables with the paths set correctly as
described in docs/INSTALL.

----------------------------------------------------------------------

Comment By: kdekker (kdekker)
Date: 2010-07-14 13:42

Message:
Just a proposed solution:
libdir may be changed to
a. default SSL lib dir, the directory as proded with-ssl=PATH/lib
b. if pkgconfig does not exist, try one of the following directories
PATH/lib/pa20_64
PATH/lib/64
PATH/lib/hpux64
etc until a directory was found where pkgconfig subdir existed.

----------------------------------------------------------------------

Comment By: kdekker (kdekker)
Date: 2010-07-14 11:52

Message:
openssl0.9.8k still uses x/lib, also for all 64bit builds.
The open ssl CHANGES file did not tell when this behavior was introduced
(or I missed something)

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3029420&group_id=976
Received on 2010-07-16