I build the ffmpeg with librtmp. My librtmp is at /opt/librtmp/lib. When I execute the ffmpeg, it said:
./ffmpeg: error while loading shared libraries: librtmp.so.0: cannot open shared object file: No such file or directory
I use ldd command it displays not found:
[qty#testing bin]# ldd ffmpeg
linux-vdso.so.1 => (0x00007fff15576000)
librtmp.so.0 => not found
libz.so.1 => /lib64/libz.so.1 (0x00002b9a71e10000)
libm.so.6 => /lib64/libm.so.6 (0x00002b9a72025000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b9a722a8000)
libc.so.6 => /lib64/libc.so.6 (0x00002b9a724c3000)
/lib64/ld-linux-x86-64.so.2 (0x00002b9a71bf2000)
I know my so at:
[qty#testing bin]# ls -alh /opt/librtmp/lib/
total 300K
drwxr-xr-x 3 root root 4.0K Sep 25 17:10 .
drwxr-xr-x 7 root root 4.0K Sep 25 17:10 ..
-rw-r--r-- 1 root root 158K Sep 25 17:10 librtmp.a
lrwxrwxrwx 1 root root 12 Sep 25 17:10 librtmp.so -> librtmp.so.0
-rwxr-xr-x 1 root root 118K Sep 25 17:10 librtmp.so.0
drwxr-xr-x 2 root root 4.0K Sep 25 17:10 pkgconfig
I found several ways to fix the problem
modify /etc/ld.so.conf, but it required a supper user
set LD_LIBRARY_PATH variable, but it is not conventient to users
pass rpath to gcc, like this
configure args for my ffmpeg
PKG_CONFIG_PATH="/opt/librtmp/lib/pkgconfig" ./configure --disable-doc \
--disable-ffserver --disable-avdevice \
--disable-postproc --disable-avfilter --disable-bsfs \
--disable-filters \
--disable-asm \
--disable-bzlib \
--enable-librtmp \
--prefix=/opt/ffmpeg \
--extra-ldflags="-Wl,-rpath,/opt/librtmp/lib"
Assume there are no source code to re-compile? How do add the shared library search path to a executable file ?
I realize that OP has probably moved on but this is the kind of thing that NixOS does regularly and they have released a tool for this very problem. Also this was a problem I had before even hearing of NixOS.
Here's an example usage of their tool patchelf
...
Likewise, you can change the RPATH, the linker search path embedded into executables and dynamic libraries:
patchelf --set-rpath /opt/my-libs/lib:/foo/lib program
This causes the dynamic linker to search in /opt/my-libs/lib and /foo/lib for the shared libraries needed by program....
From https://nixos.org/patchelf.html
You could use addrpath to add an RPATH to your elf file.
The RPATH will work like LD_LIBRARY_PATH, that is, telling the dynamic loader to search for the shared libraries in that path. RPATH will be permanently in your ELF file.
nixos
this might be nixos specific but provides an interesting insight on ldd/patchelf:
https://lastlog.de/blog/posts/playing_FTL_on_NIXOS.html
ubuntu
on ubuntu/fedora you would use: LD_LIBRARY_PATH with a starter script ./ftl, again, see my above posting about FTL and how it is deployed.
My fix to this problem is to install librtmp into /usr/local/lib and run 'sudo ldconfig' after installing it.
Ffmpeg can then be configured simply by adding --enable-librtmp.
For me this works fine: No system modifications necessary!
Related
I am trying to run a simple tcl script with tclsh8.6 that I compiled from source using a musl toolchain on x86_64 Debian.
The script, hello.tcl, looks like this:
puts hello
and when I try to run it I get the following error:
$ /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
-bash: /usr/local/x86_64-linux-musl/bin/tclsh8.6: No such file or directory
The necessary tcl libraries and include files are all installed to the prefix /usr/local/x86_64-linux-musl. The binary also exists:
$ ls -l /usr/local/x86_64-linux-musl/bin/tclsh8.6
-rwxr-xr-x 1 root root 8328 Nov 15 12:18 /usr/local/x86_64-linux-musl/bin/tclsh8.6
$ ldd /usr/local/x86_64-linux-musl/bin/tclsh8.6
linux-vdso.so.1 (0x00007ffd04718000)
libtcl8.6.so => /usr/local/x86_64-linux-musl/lib/libtcl8.6.so (0x00007f005981e000)
libc.so => /usr/local/x86_64-linux-musl/lib/libc.so (0x00007f0059587000)
I would like to keep things musl based, so I am trying to avoid a potential solution I found elsewhere, which is to reinstall tcl or tcl-dev with apt-get.
What is causing this error? Any guidance/help is greatly appreciated. Thanks :)
EDIT
As requested by some of the comments here is some additional information.
The output of the file command:
$ file /usr/local/x86_64-linux-musl/bin/tclsh8.6
/usr/local/x86_64-linux-musl/bin/tclsh8.6: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, not stripped
The output of the strace command:
strace /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
execve("/usr/local/x86_64-linux-musl/bin/tclsh8.6", ["/usr/local/x86_64-linux-musl/bin"..., "hello.tcl"], 0x7fffb8c5b278 /* 19 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++
After seeing this output, I checked to see if the loader/interpreter existed at /lib and it didn't. To fix this, I ran:
$ sudo ln -s /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1 /lib/ld-musl-x86_64.so.1
That gave me a different error when I ran tclsh8.6:
$ /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
-bash: /usr/local/x86_64-linux-musl/bin/tclsh8.6: Permission denied
Running it with sudo gives the same thing:
$ sudo /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
sudo: unable to execute /usr/local/x86_64-linux-musl/bin/tclsh8.6: Permission denied
The permissions on the interpreter and script are as follows:
$ ls -l /usr/local/x86_64-linux-musl/bin/tclsh8.6
-rwxr-xr-x 1 root root 8328 Nov 15 13:34 /usr/local/x86_64-linux-musl/bin/tclsh8.6
$ ls -l hello.tcl
-rwxr-xr-x 1 user user 11 Nov 15 12:44 hello.tcl
Hopefully this new information helps a bit more.
EDIT 2
More permission information :)
$ ls -l /lib/ld-musl-x86_64.so.1
lrwxrwxrwx 1 root root 52 Nov 16 10:04 /lib/ld-musl-x86_64.so.1 -> /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1
$ ls -l /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1
lrwxrwxrwx 1 root root 12 Nov 15 12:02 /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1 -> /lib/libc.so
$ $ ls -l /lib/libc.so
-rw-r--r-- 1 root root 246 Nov 14 15:15 /lib/libc.so
And here is the contents of /lib/libc.so:
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( //lib/libc.so.6 //lib/libc_nonshared.a AS_NEEDED ( //lib/ld-linux-x86-64.so.2 ) )
It is a linker script, which if you make executable fails and says the library is corrupted.
With the help of #Shawn I was able to figure out my problem.
tclsh8.6 was looking for the program interpreter at /lib/ld-musl-x86_64.so.1 which didn't exist - I guess when I was installing musl-cross-make it didn't set this up. To fix this problem, I simply symlinked from where ld-musl-x86_64.so.1 was located to lib:
$ sudo ln -s /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1 /lib/ld-musl-x86_64.so.1
However, I still was getting an error, but this time it was a permissions error:
$ /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
-bash: /usr/local/x86_64-linux-musl/bin/tclsh8.6: Permission denied
It turns out that ld-musl-x86_64.so.1 ended up being a symlink that resolved to /lib/libc.so which is a linker script and not the executable DSO that we want. I changed this symlink accordingly:
sudo ln -fs /usr/local/x86_64-linux-musl/lib/libc.so /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1
After that, I could execute my script and everything worked like a charm! :)
I am trying to run Quartus 13.0 in the following machine:
parrot 4.18.0-parrot10-amd64 #1 SMP Debian 4.18.10-1parrot10 (2018-10-06) x86_64 GNU/Linux.
I have finished installing Quartus 13.0 and when I try to execute it I get this error:
quartus: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory
I have read all the related questions in stack overflow and other websites but no one worked for me.
When looking for that file, I found it. I have tried to do a hard link but it doesn't work either. Search results:
┌─[pepbd#parrot]─[~]
└──╼ $ls -ld $(locate -r libpng.*\.so.*)
lrwxrwxrwx 1 root root 19 nov 19 17:09 /usr/lib/x86_64-linux-gnu/libpng16.so.16 -> libpng16.so.16.34.0
-rw-r--r-- 1 root root 210864 jul 10 13:17 /usr/lib/x86_64-linux-gnu/libpng16.so.16.34.0
-rw-r--r-- 1 root root 18272 oct 14 21:59 /usr/lib/x86_64-linux-gnu/vlc/plugins/codec/libpng_plugin.so
I had the same problem with Quartus Prime 18 on Ubuntu. This worked for me (run as sudo):
wget -q -O /tmp/libpng12.deb http://mirrors.kernel.org/ubuntu/pool/main/libp/libpng/libpng12-0_1.2.54-1ubuntu1_amd64.deb \
&& dpkg -i /tmp/libpng12.deb \
&& rm /tmp/libpng12.deb
I'm using Fedora 25.
I have a binary that needs multiple libraries. The binary can't find libRblas.so:
$ ldd XPore-Engine | less | grep not
libvtkRenderingAnnotation.so.1 => /usr/lib64/vtk/libvtkRenderingAnnotation.so.1 (0x00007fac12563000)
libRblas.so => not found
libRblas.so => not found
libRblas.so => not found
The library path is properly configured with a .conf file:
$ cat /etc/ld.so.conf.d/R-x86_64.conf
/usr/lib64/R/lib
$ ll /usr/lib64/R/lib
lrwxrwxrwx. 1 root root 11 dic 16 20:46 libopenblas.so.0 -> libRblas.so
lrwxrwxrwx. 1 root root 27 oct 31 21:16 libRblas.so -> /usr/lib64/libopenblas.so.0
-rwxr-xr-x. 1 root root 1989312 oct 31 21:16 libRlapack.so
-rwxr-xr-x. 1 root root 178856 oct 31 21:16 libRrefblas.so
-rwxr-xr-x. 1 root root 2911536 oct 31 21:16 libR.so
And I load the configuration with ldconfig:
$ ldconfig -v | grep libRblas
libopenblas.so.0 -> libRblas.so
However, after executing ldd again it returns the same output saying that libRblas.so wasn't found.
How can I fix this?
I've found a workaround provided by Tom in the Read Hat Bugzilla bug-tracking system at https://bugzilla.redhat.com/show_bug.cgi?id=1404662.
Yeah, so it looks like while R is perfectly happy using libRblas.so as a > symlink to libopenblas.so.0, externally, nothing else is.
The speedup from using openblas is significant, so the fix is to build a copy of openblas that has the libRblas.so filename and soname, and use that instead of the symlink. I have a new build of openblas going which adds this, then I'll do a new round of R builds that depend on it.
As a temporary workaround, you can run (as root):
rm -f /usr/lib64/R/lib/libRblas.so
mv /usr/lib64/R/lib/libRrefblas.so /usr/lib64/R/lib/libRblas.so
That will restore the unoptimized libRblas.so that R provides.
Oh, and run /sbin/ldconfig (as root) after moving libRrefblas.so so that the ldcache is updated.
I'm trying to execute nft , which was built from source , but it reports
$ nft
nft: error while loading shared libraries: libnftnl.so.4: cannot open shared object file: No such file or directory
I built libmnl,libnftnl,nftables from sources by runnning autogen.sh and then configuring with :
--prefix=/usr/local
these are the contents of /usr/local/lib :
$ ls -l /usr/local/lib/ | grep libnftnl
-rwxr-xr-x 1 root root 961 Mar 2 20:16 libnftnl.la
lrwxrwxrwx 1 root root 17 Mar 2 20:16 libnftnl.so -> libnftnl.so.4.0.0
lrwxrwxrwx 1 root root 17 Mar 2 20:16 libnftnl.so.4 -> libnftnl.so.4.0.0
-rwxr-xr-x 1 root root 913147 Mar 2 20:16 libnftnl.so.4.0.0
more information :
$ ldd $(which nft)
linux-vdso.so.1 => (0x00007ffd7afbf000)
libmnl.so.0 => /usr/lib/x86_64-linux-gnu/libmnl.so.0 (0x00007fc60181f000)
libnftnl.so.4 => not found
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007fc6015d8000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fc601364000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc600f9f000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fc600d75000)
/lib64/ld-linux-x86-64.so.2 (0x000055a0bd82d000)
and the contents of my ld.so.conf are :
$ cat /etc/ld.so.conf
/usr/lib/x86_64-linux-gnu/libfakeroot
# libc default configuration
/usr/local/lib
/usr/local/lib/
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/mesa-egl
/usr/lib/x86_64-linux-gnu/mesa
/usr/lib/i386-linux-gnu/mesa
# Legacy biarch compatibility support
/lib32
/usr/lib32
# Legacy biarch compatibility support
/libx32
/usr/libx32
But if I set LD_LIBRARY_PATH to '/usr/local/lib' :
$ export LD_LIBRARY_PATH=/usr/local/lib
$ ldd $(which nft)
linux-vdso.so.1 => (0x00007ffedf9b3000)
libmnl.so.0 => /usr/local/lib/libmnl.so.0 (0x00007fb58a033000)
libnftnl.so.4 => /usr/local/lib/libnftnl.so.4 (0x00007fb589e0b000)
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007fb589ba3000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fb58992f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb58956a000)
libmxml.so.1 => /usr/lib/libmxml.so.1 (0x00007fb58935b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb58913d000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fb588f14000)
/lib64/ld-linux-x86-64.so.2 (0x000055a827fb3000)
Can anybody help why it cannot find the library even if it exists in the search path ?
I forgot to run ldconfig , as pointed out by #Petesh . Problem got resolved after runnning ldconfig.
I had symbolic link to the target libs:
~/opt/OpenBLAS/lib $ ls -al
total 0
drwxrwxr-x 2 user user 59 Jul 9 13:03 .
drwxrwxr-x 5 user user 147 Jul 9 12:48 ..
lrwxrwxrwx 1 user user 64 Jul 9 13:03 libopenblas.a -> ../openBLAS_v0.2.9df/lib/libopenblas_df029_sandybridgep-r0.2.9.a
lrwxrwxrwx 1 user user 65 Jul 9 13:03 libopenblas.so -> ../openBLAS_v0.2.9df/lib/libopenblas_df029_sandybridgep-r0.2.9.so
$ echo $LD_LIBRARY_PATH
/home/user/opt/OpenBLAS/lib
Then the gcc has following args:
-L/home/user/opt/OpenBLAS/lib -lopenblas
however, after compiling, run the command it always throws out error:
error while loading shared libraries: libopenblas_df029.so.0: cannot open shared object file: No such file or directory
If I create a symbolic link libopenblas_df029.so.0 under the /home/user/opt/OpenBLAS/lib, it will then work.
Can anyone explain to me why this is happening and how can I change the behaviour?
Does this mean the libopenblas contain some suffix and the OS always append this suffix when trying to find lib file?
I think, your library "libopenblas_df029_sandybridgep-r0.2.9.so" is compiled with "-soname" switch
something like:
gcc -shared -Wl,-soname,libopenblas_df029.so.0 source.c -o libopenblas_df029_sandybridgep-r0.2.9.so
When you link against such library, your executable tries to find library by name "libopenblas_df029.so.0" ( i.e. whatever name you specified in -soname switch )
The best way to find if this is true is to run following command and look for "SONAME"
readelf -d <shared_object> | head -10
Like #Icarus3 said, the linked executable contains the name of the library as it wants to be called (the SONAME).
There should be a symbolic link from that name to the actual shared library. If it is missing, the library is not properly installed -- usually it is a sign that you need to run ldconfig to update the symbolic links and the dynamic linker cache.