Linux error cannot open shared object file no such file or directory

Error while loading shared libraries: ‘libpcre.so.0: cannot open shared object file: No such file or directory’

I got the same error, and I fixed the problem by running sudo ldconfig .

I had installed PCRE manually before passenger installation (trying to solve another error with that version of passenger) and got this error when tried to start nginx. «sudo ldconfig» helped me too. Thanks a lot!

Execute below command and restart server again.

export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH 

The message means what it says. The nginx executable was compiled to expect the PCRE (Perl-compatible Regular Expression) shared library to be available somewhere on LD_LIBRARY_PATH or specified in /etc/ld.so.conf or whatever equivalent library-locating mechanisms apply to your operating system, and it cannot find the library.

You will need to install PCRE — or configure your environment so that nginx will look for the PCRE library where it is installed.

@redroot: In the short-term (to get it working) you can add the directory where PCRE is installed to the LD_LIBRARY_PATH environment variable and try running again. If that works, then you need to investigate /etc/ld.so.conf . If it doesn’t work, then you need to check whether Ruby is 32-bit and PCRE is 64-bit, or whether Ruby is 64-bit and PCRE is 32-bit. The mixture won’t work. If you have a mixture, reinstall the correct version (bittiness) of one of the products, but PCRE alone is simpler than Ruby plus its extensions. Use file and ldd to analyze binaries and shared libraries.

As a guy who is working through nginx builds, I’m finding the configure system a bit unflexible. For example, configuring with OpenSSL assumes you want linking to a shared object. Its appears impossible to force static linking to libssl and libcrypto when both the static archive and shared object are present. Careful placement of -Bstatic and -Bshared does not help.

It’s an old post, but hopefully might be useful for someone. I was trying to install/start up an older version of NGINX on Amazon-Linux 2 and encountered this error. NGINX is expecting libpcre.so.0 , but the library wasn’t available on Amazon-Linux 2.

1. Searched for a later version of libpcre.so using find / -name libpcre.so*
2. I found libpcre.so.1 symlinked to libpcre.so.1.2. 0 in /usr/lib64/
3. I created a new symlink to libpcre.so.1.2.0 and named it libpcre.so.0 using ln -s libpcre.so.1.2.0 libpcre.so.0
4. Restarted NGINX and it worked

There are few recommendations, with this I have solved the issue which I had.

• As mentioned above add the lib path in the /etc/ld.so.conf and check the same is updated or not by using ldconfig -v
• Add the LD_LIBRARY_PATH in the .bash_profile and refresh the same with . . bash profile .
• If the lib file is not get updated then use the updatedb to refresh the library list.

I got the same error after I installed ClamAV, Antivirus for my Linux server.

[root@10 ~]# yum install clamav clamav-db clamd -y Loaded plugins: aliases, changelog, kabi, presto, product-id, refresh-packagekit, security, subscription-manager, tmprepo, verify, : versionlock This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Loading support for Red Hat kernel ABI Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package clamav.x86_64 0:0.100.3-1.el6 will be installed --> Processing Dependency: libjson-c.so.2()(64bit) for package: clamav-0.100.3-1.el6.x86_64 ---> Package clamav-db.x86_64 0:0.100.3-1.el6 will be installed ---> Package clamd.x86_64 0:0.100.3-1.el6 will be installed --> Running transaction check ---> Package json-c.x86_64 0:0.11-13.el6 will be installed --> Finished Dependency Resolution Dependencies Resolved ==================================================================================================================================== Package Arch Version Repository Size ==================================================================================================================================== Installing: clamav x86_64 0.100.3-1.el6 base 1.3 M clamav-db x86_64 0.100.3-1.el6 base 150 M clamd x86_64 0.100.3-1.el6 base 243 k Installing for dependencies: json-c x86_64 0.11-13.el6 base 27 k Transaction Summary ==================================================================================================================================== Install 4 Package(s) Total download size: 152 M Installed size: 154 M Downloading Packages: Setting up and reading Presto delta metadata Processing delta metadata Package(s) data still to download: 152 M (1/4): clamav-0.100.3-1.el6.x86_64.rpm | 1.3 MB 00:00 (2/4): clamav-db-0.100.3-1.el6.x86_64.rpm | 150 MB 00:01 (3/4): clamd-0.100.3-1.el6.x86_64.rpm | 243 kB 00:00 (4/4): json-c-0.11-13.el6.x86_64.rpm | 27 kB 00:00 ------------------------------------------------------------------------------------------------------------------------------------ Total 100 MB/s | 152 MB 00:01 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Installing : json-c-0.11-13.el6.x86_64 1/4 /sbin/ldconfig: libraries libpcre.so.0 and libpcre.so.1 in directory /lib64 have same soname but different type. Installing : clamav-db-0.100.3-1.el6.x86_64 [############################# ] 2/4 Installing : clamav-db-0.100.3-1.el6.x86_64 2/4 Installing : clamav-0.100.3-1.el6.x86_64 3/4 Installing : clamd-0.100.3-1.el6.x86_64 4/4 Verifying : clamd-0.100.3-1.el6.x86_64 1/4 Verifying : clamav-0.100.3-1.el6.x86_64 2/4 Verifying : json-c-0.11-13.el6.x86_64 3/4 Verifying : clamav-db-0.100.3-1.el6.x86_64 4/4 Installed: clamav.x86_64 0:0.100.3-1.el6 clamav-db.x86_64 0:0.100.3-1.el6 clamd.x86_64 0:0.100.3-1.el6 Dependency Installed: json-c.x86_64 0:0.11-13.el6 Complete! [root@10 ~]# [root@10 ~]# grep: error while loading shared libraries: libpcre.so.0: wrong ELF class: ELFCLASS32 grep: error while loading shared libraries: libpcre.so.0: wrong ELF class: ELFCLASS32 [root@10 ~]# grep: error while loading shared libraries: libpcre.so.0: wrong ELF class: ELFCLASS32 

Later I found below libraries got deleted from /lib64

libjson-c.so.2.0.1 libjson.so.0.1.0 libpcre.so.0 -> libpcre.so.0.0.1 

I copied those from other server and uninstalled ClamAV.

Running Transaction Erasing : clamd-0.100.3-1.el6.x86_64 1/3 Erasing : clamav-0.100.3-1.el6.x86_64 2/3 warning: /etc/freshclam.conf saved as /etc/freshclam.conf.rpmsave Erasing : clamav-db-0.100.3-1.el6.x86_64 3/3 Verifying : clamd-0.100.3-1.el6.x86_64 1/3 Verifying : clamav-0.100.3-1.el6.x86_64 2/3 Verifying : clamav-db-0.100.3-1.el6.x86_64 3/3 Removed: clamav.x86_64 0:0.100.3-1.el6 clamav-db.x86_64 0:0.100.3-1.el6 clamd.x86_64 0:0.100.3-1.el6 Complete! 

sending incremental file list libjson-c.so.2.0.1 libjson.so.0.1.0 libpcre.so.0 -> libpcre.so.0.0.1 

Источник

dlopen failed: cannot open shared object file: No such file or directory

The most brutal and effective way to find out where your code goes wrong is the following command which will activate the debugging mode for shared libraries and is documented here:

Then, you will be surprised that so much information pops up. Don’t worry, these information tells you which shared libraries the command you just typed needs and where to locate these needed libraries. For example, if you type reset , the screen will be reseted and then information about the shared libraries reset command needs will be printed.

Then, execute your «problematic» executable to see what’s going wrong.

PS.1 : According to your accepted mythagal’s solution :

Specify the full path to the file in dlopen

dlopen(«/full/path/to/libfile.so»);

It seemed that even though you use absolute or relative path in the dlopen function, the directory not found error will still show up. I am using CentOS, and my Debian is also having this problem. So I think the first solution mythagal provide is wrong. You can verify that in the «debugging» mode I mentioned above.

PS.2: If you «install» or «compile» a shared library rather than install it through package manager, you MUST run sudo ldconfig /path/where/not/found/shared/library/reside to notify the system of the newly added shared library. For example :

cp /etc/ld.so.cache ~/ld.so.cache.backup #cp -r /etc/ld.so.conf.d ~/ld.so.conf.d.backup #sometimes this backup is unnecessary. #cp /etc/ld.so.conf ~/ld.so.conf.backup #sometimes this backup is unnecessary. sudo ldconfig /PATH/WHERE/NOT/FOUND/SHARED/LIBRARY/RESIDE ###I am omitting the cp commands to roll back. ###For example, sudo cp -f ld.so.cache /etc/ld.so.cache 

To understand what’s going on here, please carefully read all the contents in the link above.

PS.3 : You can always use the command export LD_DEBUG=help , export LD_DEBUG=libs to figure out how -rpath or LD_LIBRARY_PATH solve your problem. You will love this debugging mode.

PS.4: A less brutal way to figure out what’s going wrong:

ldd ./YOURproblematicEXECUTABLE 

This command can tell you whether your shared library to be opened is located or not. Besides, there are so many ways to fix your problem and each way has its limitation and application. So I strongly suggested you read the link I provide you above and understand how to choose the way to solve your problem. After reading that, if you actually feel like being very «OK», you can also read this Better understanding Linux secondary dependencies solving with examples for deeper understanding.

Источник

error while loading shared libraries: libgsl.so.0: cannot open shared object file: No such file or directory

I use gsl. After I compiled my .cpp file and run it, I faced with below error: error while loading shared libraries: libgsl.so.0: cannot open shared object file: No such file or directory I found same as this problem in: https://groups.google.com/forum/#!topic/cortex_var/6vluX7pP0Sk & Linux error while loading shared libraries: cannot open shared object file: No such file or directory & http://www.gnu.org/software/gsl/manual/html_node/Shared-Libraries.html And I have done as in the above links wrote but the error is still remained. Can anyone help me?

It is located at right place I reinstalled gsl from terminal and above error is not exist now. But I have segmentation fault and should come over it. Thanks any way

Thank you for your link provided. I found gnu.org/software/gsl/manual/html_node/Shared-Libraries.html is useful to me. Have you solved your problem?

8 Answers 8

To make it work do the following steps

$LD_LIBRARY_PATH= path to your gsl lib folder inside the gsl installation folder $export LD_LIBRARY_PATH 

First, you need to locate the file (libgsl.so.0). You can do this, for example, by using the find command:

sudo find / -name "libgsl.so.0" 

Let us assume, the file is located in /usr/local/lib . (If the file has not been found, install the corresponding package or download the source, build it and install it.) Now, you have two options:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib export LD_LIBRARY_PATH 

This adds the path of the library to an environment variable. The disadvantage of this option is, that it is only valid for the current session. It will not work for other users. It will not work once you log off and on again.

Review your /etc/ld.so.conf . If /usr/local/lib is not listed there, add it. Now, run ldconfig to detect the shared object file and add it to some system-wide index.

Источник