search for: ldd

Hi all, Will ldd display the paths to different libraries depending on their locations? I'm trying to build libxml2 version 2.9.6 in /usr/local with a newer version of zlib (1.2.8) than what are in the system folders for CentOS 6.8. I get the following output from ldd: $ ldd ./libxml2.so ./libxml2.so: /lib...

...nder <alice at domblogger.net> said: >> So when building curl, it links curl against the libcurl in the >> buildroot and not against the libcurl it just compiled? >> >> No other packages I know of do that. > > No, that is not what it does. If you posted the full ldd output like I > asked, rather than grepping out bits, you'd see it loading the system > libcurl. > > When you run ldd against an arbitrary binary, ldd uses the system > directories to resolve dependencies. The libcurl you just built is not > in any of those directories, but t...

Hi! Is there any way to do sort of an ldd-style function to see what dlls are needed by certain executables or other dlls in wine? Thanks! -Steven

...ings, and I got a curl and libcurl that do not in > any way depend on libssl. It is most definitely libssh2.so that > requires libssl.so. > > If you want help, you need to stop repeating your claims and show some > actual commands run, output, versions, etc. > [alice at pern ~]$ ldd /usr/bin/curl |grep crypto libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f4524390000) libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f45234ca000) [alice at pern ~]$ rpm -qf /lib64/libcrypto.so.10 openssl-libs-1.0.1e-51.el7_2.5.x86_64 [alice at pern ~]$ That's with stock CentOS...

Hi people, I have a 64 bit Centos machine. My problem is that I can't run 32 bit applications on that. I can compile with the 32 bit option my sources, but when I'm trying to run them I obtain the following error message: -bash: ./a.out: cannot execute binary file And the file a.out returns the following: a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux

On 08/03/2016 06:40 PM, Chris Adams wrote: > Once upon a time, Alice Wonder <alice at domblogger.net> said: >> [alice at pern root]$ ldd builddir/build/BUILDROOT/curl-7.29.0-26.el7_2.awel.libre.0.x86_64/usr/bin/curl >> |grep crypto >> libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fb6e00a5000) >> libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fb6df3e8000) > > Here is your problem - unless you...

Hello, I am currently switching to ldd from ld.bfd on a cross-platform embedded project and am facing a behaviour difference when using the same linker scripts with ld.bfd and ldd. Could anybody please give me a more reliable direction I should go with to get the same behaviour from both of the linkers? Target binary format is a 32-bit...

On 08/03/2016 06:30 PM, Chris Adams wrote: > Once upon a time, Alice Wonder <alice at domblogger.net> said: >> [alice at pern ~]$ ldd /usr/bin/curl |grep crypto >> libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f4524390000) >> libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f45234ca000) > > What do the following show: > > ldd /usr/bin/curl > ldd /usr/lib64/libcurl.so.4 > ldd /usr...

...her sample program hi.c on the ARM laptop and compared both - the one cross compiled "hello" and the other self host compiled "hi". Output message of utility "file" is almost the same except Linux version, one is 2.6.16 and the other is 2.6.31. But the output of "ldd" shows something meaningful. ldd hi libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6ecf000) /lib/ld-linux-armhf.so.3 (0xb6fc3000) ldd hello not a dynamic executable I guess I have to use a cross toolchain for my ARM target - AC 100. It has been equipped with Ubuntu 12.0...

...hi.c on the ARM laptop and compared > both - the one cross compiled "hello" and the other self host compiled "hi". > > Output message of utility "file" is almost the same except Linux > version, one is 2.6.16 and the other is 2.6.31. But the output of "ldd" > shows something meaningful. This is curious based on the output from ldd below, does file report each as, "dynamically linked". > > ldd hi > libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6ecf000) > /lib/ld-linux-armhf.so.3 (0xb6fc3000) > &gt...

...non], product=0x1908 [CanoScan]) at libusb:001:010 >> >> I perused my notes for the old computer but did not see I installed any additional software to get it going but I might be wrong. >> >> What have I missed? >> > On my C7 box, simple-scan requires libsane. try: ldd simple-scan |grep -i sane. > > # ldd /usr/bin/simple-scan | grep -i sane > libsane.so.1 => /lib64/libsane.so.1 (0x00007f3668291000) > > > ldd doesn't show any other sane dependencies, but I'd sorta think > that simple-scan would also need sane-backends as well. Here...

I have a number of programs I wrote on Centos 5 (x86_64) and for one of the programs I do ldd programX linux-vdso.so.1 => (0x00007fff2cb86000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003528600000) libm.so.6 => /lib64/libm.so.6 (0x0000003527e00000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0000003531400000) libz.so.1 => /usr/l...

...enerated from it is the following: LBB0_3: // %vector.body.preheader REGVEC0 = 0 mov r0, 0 std -48(r10), r0 std -128(r10), REGVEC0 jmp LBB0_4 LBB0_4: // %vector.body ldd REGVEC0, -128(r10) ldd r0, -48(r10) I am surprised that the BPF scalar instructions ldd and std use vector register REGVEC0, which have type v8i64. For example, the TableGen definition of the LOAD instruction taken from BPFInstrInfo.td is: class LOADi64<bits&...

On 07/30/2014 10:06 AM, Larry Evans wrote: > On 07/30/2014 12:35 AM, Ben Pope wrote: >> On Wednesday, July 30, 2014 01:31 PM, Ben Pope wrote: >> >>> ldd your_built_clang | grep libstdc++ >>> chrpath -l your_built_clang >> >> Hmm, where "your_built_clang" should be the actual failing executable: >> /home/evansl/dwnlds/llvm/3.5rc1/build/Release+Asserts/bin/llvm-tblgen >> >> Ben > Here's the resu...

On Wednesday, July 30, 2014 01:31 PM, Ben Pope wrote: > ldd your_built_clang | grep libstdc++ > chrpath -l your_built_clang Hmm, where "your_built_clang" should be the actual failing executable: /home/evansl/dwnlds/llvm/3.5rc1/build/Release+Asserts/bin/llvm-tblgen Ben

sorry to start a new thread. didnt know how to continue the other one i started. $ ldd rubyeventmachine.so rubyeventmachine.so: rubyeventmachine.so: Exec format error rubyeventmachine.so: exit status 1 dont mean to waste your time, just been asked on irc whether i''ve had a look into eventmachine and i mentioned that it did not compile properly on my box. so if this is too m...

...arams: Fatal: Couldn't load required plugin /usr/local/Dovecot-2.2.25/lib/dovecot/libssl_iostream_openssl.so: dlopen() failed: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory Jul 4 01:08:43 myhost dovecot: ssl-params: Error: child process failed with status 22784 ldd /usr/local/Dovecot-2.2.25/lib/dovecot/libssl_iostream_openssl.so linux-gate.so.1 => (0x00e8c000) libcrypto.so.1.0.0 => not found libssl.so.1.0.0 => not found librt.so.1 => /lib/librt.so.1 (0x00be4000) libc.so.6 => /lib/libc.so.6 (0x001a6000)...

Are you asking if the new libstdc++ is statically linked into your app only for the new functions but your app remains dynamically linked to the old one for the parts of C++ that have remained unchanged, the answer is ?no?. Your app is linked to the new library, period. You can use ldd(1) to prove this to yourself. I am not so sure. That is what I thought, but then I compiled something with a compiler from devtoolset (5.2.1) with --std=c++11 flag. ldd gives me: ldd a.out linux-vdso.so.1 => (0x00007fff6e5ff000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000039d840000...

Hal, I very well understand that LDD may not be in a good state for PPC32, and it would definitely need some improvements sooner or later. In fact I even submitted a patch adding a relocation to ldd just a few hours ago. However, this particular case is not related to LDD, it is a design issue and furthermore a regression in LLVM its...

...ure of the history of the server's libpcap install.  Too many chefs and only one pot.  I know, that doesn't help.  Your question did prompt me to check versions and discover that there's a 1.9.0 version in the BaseOS repo.  I removed the previous package and loaded the new one. a quick ldd test ~]# ldd /usr/lib/systemd/systemd | grep libpcap     libpcap.so.1 => /lib64/libpcap.so.1 (0x00007fc395a38000) but when I ran virt-sysprep it complains about libpcap again: "systemd-tmpfiles: error while loading shared libraries: libpcap.so.1: cannot open shared object file: No such fil...