2

When attempting to run Cloud9 IDE locally after its installation I receive this error:

# bin/cloud9.sh
Linux 64 bit
support/node-builds-v4/node-linux64: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory

It looks strange, because the library is in /lib, /usr/lib and other locations through symbolic links.

For check, here is the main file:

# ls -l /usr/lib | grep libssl
-r-xr-xr-x. 1 root root   319816 Oct  6  2014 libssl.so.0.9.8

Why does it not find the file, does it need to be included in any other $PATH variable or what can be the cause?

Updates:

It seems to be a wider problem with ssl:

# git submodule update --init --recursive
Cloning into 'support/sass'...
fatal: remote error:
  Repository not found.
Clone of 'git://github.com/visionmedia/sass.js.git' into submodule path 'support/sass' failed
Failed to recurse into submodule path 'support/connect'

The failed module needs ssl to download, while the others that downloaded don't:

# cat .gitmodules
[submodule "support/socket.io-client"]
    path = support/socket.io-client
    url = http://github.com/ajaxorg/socket.io-client.git
[submodule "support/uglify-js"]
    path = support/uglify-js
    url = http://github.com/ajaxorg/UglifyJS.git
[submodule "support/connect"]
    path = support/connect
    url = https://github.com/ajaxorg/connect.git

Check openssl version:

# yum list installed openssl
Loaded plugins: refresh-packagekit, security, ulninfo
Installed Packages
openssl.x86_64                      1.0.1e-42.el6                      

64 bit installed openssl libraries:

# ls -l /usr/lib64 | grep libssl
-rwxr-xr-x.  1 root root   261248 Nov  4 10:37 libssl3.so
lrwxrwxrwx.  1 root root       16 Dec  1 10:30 libssl.so -> libssl.so.1.0.1e
-rwxr-xr-x.  1 root root   324680 Jun  5  2014 libssl.so.0.9.8e
lrwxrwxrwx.  1 root root       16 Dec  1 10:29 libssl.so.10 -> libssl.so.1.0.1e
-rwxr-xr-x.  1 root root   444184 Jul 23 09:43 libssl.so.1.0.1e
lrwxrwxrwx.  1 root root       16 Dec  3 11:29 libssl.so.6 -> libssl.so.0.9.8e
2

As you can see by searching for an RPM with libssl.so.0.9.8, this is an old file, and unlikely to be part of the RPM which you listed for openssl. You can see what files are part of the RPM using

rpm -ql openssl.x86_64

and further, you can see what RPM that file might belong to by

rpm -qf /usr/lib/libssl.so.0.9.8

and also what architecture the file uses by

file /usr/lib/libssl.so.0.9.8

The most likely explanation is (one or more of):

  • the file was copied from some other machine
  • it is a 32-bit library
  • the ldconfig path for 64-bit libraries uses /usr/lib64 (not /usr/lib).

A 64-bit application cannot load a 32-bit shared library, and will only find its libraries where ldconfig says it may.

  • Excellent, then I'm thinking about just dynamically linking the new SSL library into the location of the old file (libssl.so.0.9.8) – Peter Gerhat Dec 3 '15 at 11:54
  • That might work (openssl seems to rarely break forward-compatibility). – Thomas Dickey Dec 3 '15 at 11:58
  • The setup worked with the ln -fs /usr/lib64/libssl.so.0.9.8e /usr/lib64/libssl.so.0.9.8 – Peter Gerhat Dec 3 '15 at 12:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.