ROSA Linux Bugzilla – Bug 5246
gives error: undefined symbol: TLSv1_1_client_method
Last modified: 2015-03-24 03:31:33 MSK
Description of problem:
wget 1.16.1 crashes with error: undefined symbol: TLSv1_1_client_method, when launched from Konsole
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.launch wget from konsole
It looks like you have some wrong SSL library installed in your system which is picked up instead of the system one.
Could you provide output of the following commands:
$ rpm -qf /usr/lib64/libssl.so.1.0.0
$ readelf -Wa /usr/lib64/libssl.so | grep TLSv1_1_client_method
$ ldd /usr/bin/wget
Here it is:
[root@DESKTOP-1 andrea]# readelf -Wa /usr/lib64/libssl.so | grep TLSv1_1_client_method
559: 0000000000033410 53 FUNC GLOBAL DEFAULT 11 TLSv1_1_client_method
[root@DESKTOP-1 andrea]# ldd /usr/bin/wget
linux-vdso.so.1 => (0x00007fff4c3ec000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f718ab41000)
libssl.so.1.0.0 => /usr/StorMan/ssl/lib/libssl.so.1.0.0 (0x00007f718a8d3000)
libcrypto.so.1.0.0 => /usr/StorMan/ssl/lib/libcrypto.so.1.0.0 (0x00007f718a4e5000)
libz.so.1 => /lib64/libz.so.1 (0x00007f718a2ca000)
libidn.so.11 => /usr/lib64/libidn.so.11 (0x00007f718a095000)
libc.so.6 => /lib64/libc.so.6 (0x00007f7189cd1000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7189ab4000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f71898af000)
I forgot to mention that wget ver 15 works fine on my system.
A corrupted copy of wget on the repos?
(In reply to comment #2)
> A corrupted copy of wget on the repos?
No. Here is the culprit:
> libssl.so.1.0.0 => /usr/StorMan/ssl/lib/libssl.so.1.0.0
> libcrypto.so.1.0.0 => /usr/StorMan/ssl/lib/libcrypto.so.1.0.0
You have 'StorMan' installed in your system which overlaps system OpenSSL libraries. In normal situation, you would get the output like this:
libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0
It looks like OpenSSL libraries in StorMan are too old and don't provide symbols necesary for our wget and other problems. The simplest way to resolve your issues is to remove StorMan (since this is not a package from our repositories, we can't fix it by ourselves).
Alternatively, you can take a look at your LD_LIBRARY_PATH variable:
$ echo $LD_LIBRARY_PATH
It's likely that this variable contains path to /usr/StorMan/ssl/lib. If so, then try to launch wget in the following way:
$ LD_LIBRARY_PATH='' wget
Thanks, I already pointed out this problem to Adaptec support. I can't remove StorMan as it is the interface to my raid array.
Investigating, I found that there are two env variables set:
that I am not able to permanently remove: export -n and unset commands don't have effect after a reboot. Any Idea about how to remove them permanently?
One of the proper ways is to write simple Shell wrapper for Storman executables that would set OPENSSL_HOME and OPENSSL_BIN variables and then launch real executables. Though I don't know how much wrappers will be required (i.e. how many files should have these variables to be set). And I believe that this task should be done by SotrMan developers:)
If you want to unset these variable on every boot, then you can try to add "unset OPENSSL_HOME OPENSSL_BIN" to your ~/.bash_profile. But I am not sure if this doesn't break anything related to Storman.
Finally, you can try to replace problematic libraries in /usr/StorMan/ssl/lib/ with symlinks to corresponding files in /usr/lib64. Since the soname is the same, the libraries in /usr/lib64 should be backward compatible with the ones provided by Storman, so Storman should be able to work with that libs.
Thank you for your support.
Adaptec already replied to my bug report and I supplied them the information they requested, so I suppose that they're working to solve the bug.
In the meantime I will try your suggestions.
I can consider closed this bug.
Do you know if somebody is taking a look to my bug 5259? It's really annoying and obliges me to use windows for my writings in Italian.
Thank you again