Am 29.05.2015 um 15:16 schrieb Wang, Andy:
You might want to reconsider that unless you really really are sure you know
what you're doing.
On a linux distro, the system installed openssl is considered a fundamental
platform infrastructure library. I.e. many many things rely on it. openssl
versions are not backward compatible.
So if you don't rebuild all of your distro installed dependencies on openssl,
you've likedly just screwed up runtime linking of alot of things.
Also, the system installed library and the openssl config makefiles may be
using incompatible soname mechanisms, which could explain why you're able to
link but not run (i.e. at linktime it may be finding the right library, but at
runtime it's not).
I didn't follow the whole thread, but about linking versus running:
at link time the linker will use the files libssl.so and libcrypto.so
(or libssl.a and libcrypto.a). Because all it is given is -lssl and
-lcrypto as flags.
It will look in those files for an entry named SONAME. On linux you can
see that name by issuing
objdump -p /path/to/my/libssl.so
and
objdump -p /path/to/my/libcrypto.so
Example output:
/path/to/my/libssl.so: file format elf64-x86-64
Program Header:
...
Dynamic Section:
NEEDED libcrypto.so.1.0.0
NEEDED libdl.so.2
NEEDED libz.so.1
NEEDED libc.so.6
SONAME libssl.so.1.0.0
...
Version References:
required from libc.so.6:
0x09691a75 0x00 02 GLIBC_2.2.5
Here you can see the SONAME is libssl.so.1.0.0. This name is added as a
dependency into the linked binary. At runtime the runtime linker will
look for this file, not for libssl.so.
During installation of lobssl.so (resp. libcrypto.so) typically the
files get linked using a symlink, so it would make no difference. If you
start to overwrite parts of the system installation, the two names might
point to different content.
About compatibility: OpenSSL 1.0.0 up to OpenSSL 1.0.2 have compatible
APIs, that's why the SONAME ends with .1.0.0 in all three cases. It is
definitely possible to upgrade, i.e. use a newer version in the 1.0.0 to
1.0.2 range during runtime than was used during compile/link time. The
other way round only holds for patch versions with the same first three
digits.
The SSL_CONF_CTX_* symbols you were originally referring to are only
part of 1.0.2. So it seems you compiled against header files from 1.0.2
and likely also loinked against a 1.0.2 libssl.so, but at runtime the
libssl.so.1.0.0 that the runtime linker finds is version 1.0.0 or 1.0.1.
The runtime linker has a search path that is defined on the system and
can be influenced using LD_LIBRARY_PATH. The compile time linker is also
influenced by compile "-L" flags.
Whether some specific libssl.so (or libssl.so.1.0.0) file contains the
symbol or not can be checked using the "nm" command:
nm /path/to/my/libssl.so1.0.0 | grep SSL_CONF_CTX
Example output here:
00000000000581a0 T SSL_CONF_CTX_clear_flags
0000000000058180 T SSL_CONF_CTX_finish
0000000000058250 T SSL_CONF_CTX_free
00000000000582f0 T SSL_CONF_CTX_new
0000000000058280 T SSL_CONF_CTX_set1_prefix
0000000000058190 T SSL_CONF_CTX_set_flags
00000000000581b0 T SSL_CONF_CTX_set_ssl
0000000000058200 T SSL_CONF_CTX_set_ssl_ctx
If the symbols are not contained you will get no hits, if they are only
referred in the lib but contained in another depenency lib, you get a
"U" marker instead of the "T" (also see the nm man page for more
possible cases).
HTH
Rainer
