ldd

问题 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

问题 I have not been able to figure out why my binary is not loading. It is a dylib loaded by MATLAB (MEX-file), and links to quite a few dylibs in different locations. MATLAB tells me it cannot load the MEX-file, but I cannot figure out which of its dependencies it cannot find. Does anybody have any suggestions for how to debug something like this? On Linux, ldd is the perfect tool to debug this problem. People keep saying that otool -L is the MacOS equivalent to the Linux ldd , but this is not

问题 When I run ldd program I get an output of the form linux-gate.so.1 => (0xb77ae000) libstdc++.so.6 => /lib/libstdc++.so.6 (0xb76bc000) libm.so.6 => /lib/libm.so.6 (0xb7691000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7674000) libc.so.6 => /lib/libc.so.6 (0xb74c2000) /lib/ld-linux.so.2 (0xb77af000) Can you explain the output and the reason linux-gate.so.1 and ld-linux.so.2 show differently than other entries? What are their roles? 回答1: I hope that you're not asking about the main entries, which

问题 I have created a cross compiled arm executable. I want to find the library dependency of the executable. I am using ubuntu natty and installed arm-linux-gnueabi tool chain, which does not contain ldd. Is there a tool available to view arm executables library dependancy in linux. 回答1: This is a bit of a kluge, but it's the best solution I could find, and it really works quite well for basic use - just save this script as "arm-none-linux-gnueabi-ldd" with your other cross tools. #!/bin/sh arm

问题 I have Ubuntu 14.04. It came with openssl 1.0.1f. I want to install another openssl version (1.0.2) and I want to compile it by myself. I configure it as follows: LDFLAGS='-Wl,--export-dynamic -L/home/myhome/programs/openssl/i/lib -L/home/myhome/programs/zlib/i/lib' CPPFLAGS='-I/home/myhome/programs/openssl/i/include -I/home/myhome/programs/zlib/i/include' ./config --prefix=/home/myhome/programs/openssl/i \ zlib-dynamic shared --with-zlib-lib=/home/myhome/programs/zlib/i/lib \ --with-zlib

问题 How do I find out what DLLs an executable depends on? On systems with the GNU development toolchain ( gcc &c) I use ldd for that, but what about the clang systems, like, e.g., Mac OS X (which does not have ldd )? 回答1: On Mac OSX, you'd use otool -L instead of ldd . This works regardless of the compiler you used. Other operating systems may have yet other tools; e.g. on Windows you'd use Dependency Walker . 来源： https://stackoverflow.com/questions/23697641/what-is-the-clang-analogue-of-ldd

问题 I'm unable to compile anything in my linux pc. I have no idea why, probably I've installed some package and made a mess. I've uninstalled and reinstalled gcc and other packages, but no good news.. still this problem. This is the message: /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse- linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/crt1.o: unrecognized relocation (0x29) in section `.text' Any idea of what does it mean and how to fix this problem? cheers 回答1:

问题 I am using ldd to show the dynamic library on Fedora/x86, and it shows different results each time it is used. Is that expected? Or is there an explanation? I remember it shows a fixed result on PPC/Linux. `ldd /bin/ls linux-gate.so.1 => (0x00e5b000) librt.so.1 => /lib/librt.so.1 (0x00c0c000) libselinux.so.1 => /lib/libselinux.so.1 (0x0095d000) libcap.so.2 => /lib/libcap.so.2 (0x00110000) libacl.so.1 => /lib/libacl.so.1 (0x00331000) libc.so.6 => /lib/libc.so.6 (0x00115000) libpthread.so.0 =>

问题 I have a binary for which ldd shows an unexpected dependency und libicuuc (from "icu"). #ldd A [...] libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007faaf9722000) libicuuc.so.49 => /usr/lib64/libicuuc.so.49 (0x00007faaf5689000) Since on this system libxml depends dynamically on libicuuc, it makes sense that ldd enventually ends up finding it, but is it expected that libicuuc also appears in the ldd output for A? Is there some command to retrieve only the libraries that are linked in as

问题 #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <sys/stat.h> #include <sys/types.h> #include <sys/mman.h> #include <errno.h> #include <fcntl.h> #include <elf.h> Elf64_Rela *retab; Elf64_Rela *retab_end; Elf64_Ehdr *ehdr; Elf64_Shdr *shdr; char *strtab; void elf_open(char *filename) { int fd = open(filename, O_RDONLY); struct stat sbuf; fstat(fd, &sbuf); void *maddr = mmap(NULL, sbuf.st_size, PROT_READ, MAP_SHARED, fd, 0); close(fd); ehdr = maddr; shdr =