Bug 5246 - gives error: undefined symbol: TLSv1_1_client_method
: gives error: undefined symbol: TLSv1_1_client_method
Status: RESOLVED NOTABUG
Product: Desktop Bugs
Classification: ROSA Desktop
Component: -Enter Bugs Here-
: Fresh
: All Linux
: Normal normal
: ---
Assigned To: Desktop Triage Team
: Desktop Triage Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-03-20 20:10 MSK by andrea_scopelliti
Modified: 2015-03-24 03:31 MSK (History)
1 user (show)

See Also:
RPM Package: wget-1.16.1-1-rosa2014.1.x86_64.rpm
ISO-related:
Bad POT generating:
Upstream:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description andrea_scopelliti 2015-03-20 20:10:00 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):


How reproducible:


Steps to Reproduce:
1.install wget-1.16.1-1-rosa2014.1.x86_64.rpm
2.launch wget from konsole
3.
Comment 1 Denis Silakov 2015-03-21 23:23:11 MSK
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
Comment 2 andrea_scopelliti 2015-03-22 03:38:22 MSK
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]# 
[root@DESKTOP-1 andrea]# 
[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)
        /lib64/ld-linux-x86-64.so.2 (0x00007f718adda000)
[root@DESKTOP-1 andrea]# 

I forgot to mention that wget ver 15 works fine on my system. 
A corrupted copy of wget on the repos?
Comment 3 Denis Silakov 2015-03-22 11:42:26 MSK
(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
Comment 4 andrea_scopelliti 2015-03-22 19:42:03 MSK
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:

OPENSSL_HOME=/usr/StorMan/ssl
OPENSSL_BIN=/usr/StorMan/ssl/bin

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?
Comment 5 Denis Silakov 2015-03-24 00:12:49 MSK
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.
Comment 6 andrea_scopelliti 2015-03-24 03:30:57 MSK
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

Andrea Scopelliti