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 => /lib/libpthread.so.0 (0x00bc9000)
/lib/ld-linux.so.2 (0x009d2000)
libdl.so.2 => /lib/libdl.so.2 (0x00680000)
libattr.so.1 => /lib/libattr.so.1 (0x00447000)
ldd /bin/ls
linux-gate.so.1 => (0x00f76000)
librt.so.1 => /lib/librt.so.1 (0x00494000)
libselinux.so.1 => /lib/libselinux.so.1 (0x0095d000)
libcap.so.2 => /lib/libcap.so.2 (0x009e9000)
libacl.so.1 => /lib/libacl.so.1 (0x00365000)
libc.so.6 => /lib/libc.so.6 (0x00732000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00b61000)
/lib/ld-linux.so.2 (0x002a7000)
libdl.so.2 => /lib/libdl.so.2 (0x002f0000)
libattr.so.1 => /lib/libattr.so.1 (0x00447000)`
Fedora uses address space randomization as part of its various security measures. ldd works by actually loading the shared objects and showing where they end up. Putting the two together results in the given observations.
Related
I have a problem with shared libraries, Command show warning each time when it run's,
PHP Warning: PHP Startup: Unable to load dynamic library 'xxxx.so'
whereas it run fine with not issues, i want to remove libcrypto.so.1.0.0 => not found this line from list so that it will not look for this shared library.
ldd ...php/ext/curl.so
linux-vdso.so.1 => (0x00007ffe1a65f000)
libcurl.so.4 => /lib/libcurl.so.4 (0x00007fb9fdd8f000)
libssl.so.1.0.0 => /lib/libssl.so.1.0.0 (0x00007fb9fdb1f000)
libcrypto.so.1.0.0 => not found
libc.so.6 => /lib64/libc.so.6 (0x00007fb9fd751000)
libssl.so.1.1 => /lib/libssl.so.1.1 (0x00007fb9fd4c0000)
libcrypto.so.1.1 => /lib/libcrypto.so.1.1 (0x00007fb9fcff7000)
libldap-2.4.so.2 => /lib/libldap-2.4.so.2 (0x00007fb9fcdb5000)
liblber-2.4.so.2 => /lib/liblber-2.4.so.2 (0x00007fb9fcba8000)
libz.so.1 => /lib/libz.so.1 (0x00007fb9fc990000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb9fc774000)
libcrypto.so.1.0.0 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb9fc570000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb9fe22e000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fb9fc356000)
libcrypto.so.1.0.0 => not found
what to do ?
I'm having problems with a library, which cannot be found, despite being there in proper version.
ldd /lib/libQt5Core.so
linux-gate.so.1 (0xb77ac000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb71d4000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb71b9000)
libicui18n.so.57 => /lib/i386-linux-gnu/libicui18n.so.57 (0xb6f20000)
libicuuc.so.57 => /lib/i386-linux-gnu/libicuuc.so.57 (0xb6d74000)
libicudata.so.57 => /lib/i386-linux-gnu/libicudata.so.57 (0xb54f6000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb54f1000)
libgthread-2.0.so.0 => /lib/i386-linux-gnu/libgthread-2.0.so.0 (0xb54ee000)
libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb53c0000)
libstdc++.so.6 => /lib/i386-linux-gnu/libstdc++.so.6 (0xb5242000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb5140000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb5120000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb4f47000)
/lib/ld-linux.so.2 (0xb77af000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb4ed0000)
The libQt5Core library is in /lib and has all dependencies met. But if something wishes to use it:
ldd /lib/libQt5Concurrent.so
linux-gate.so.1 (0xb7735000)
libQt5Core.so.5 => not found
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb76f1000)
libstdc++.so.6 => /lib/i386-linux-gnu/libstdc++.so.6 (0xb7573000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7471000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7453000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb727a000)
/lib/ld-linux.so.2 (0xb7738000)
libQt5Core is no longer found. Both libs have the same architecture. Does anyone have any ideas?
Turns out it's an issue with kernel being too old. On newer ones it works fine.
It started with httpd not starting on one of my machines:
$ /usr/sbin/httpd -v
/usr/sbin/httpd: error while loading shared libraries: libexpat.so.0: cannot open shared object file: No such file or directory
There are two machines of almost identical configuration. Centos 6.6 32-bit. Both httpd binaries have an identical size and identical md5 sum.
However, the library dependencies are different. I thought those dependencies are embedded into the binary at link time. So how can the dependencies be different?
Below note the broken httpd has two extra dependencies, libexpat.so.0 (not found) and librt.so.1.
Working httpd
# ldd /usr/sbin/httpd
linux-gate.so.1 => (0xb773b000)
libm.so.6 => /lib/libm.so.6 (0xb769c000)
libpcre.so.0 => /lib/libpcre.so.0 (0xb766c000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb764d000)
libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0xb762a000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb75f9000)
libexpat.so.1 => /lib/libexpat.so.1 (0xb75d1000)
libdb-4.7.so => /lib/libdb-4.7.so (0xb745b000)
libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0xb742d000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7412000)
libc.so.6 => /lib/libc.so.6 (0xb727b000)
/lib/ld-linux.so.2 (0x49e18000)
libdl.so.2 => /lib/libdl.so.2 (0xb7275000)
libuuid.so.1 => /lib/libuuid.so.1 (0xb7270000)
libfreebl3.so => /lib/libfreebl3.so (0xb726c000)
Broken httpd
$ ldd /usr/sbin/httpd
linux-gate.so.1 => (0xb7721000)
libm.so.6 => /lib/libm.so.6 (0xb7686000)
libpcre.so.0 => /lib/libpcre.so.0 (0xb7656000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb7637000)
libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0xb761d000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb75ec000)
libexpat.so.1 => /lib/libexpat.so.1 (0xb75c4000)
libdb-4.7.so => /lib/libdb-4.7.so (0xb744e000)
libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0xb7429000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb740e000)
libc.so.6 => /lib/libc.so.6 (0xb7277000)
/lib/ld-linux.so.2 (0x00871000)
libdl.so.2 => /lib/libdl.so.2 (0xb7271000)
libexpat.so.0 => not found
libuuid.so.1 => /lib/libuuid.so.1 (0xb726c000)
librt.so.1 => /lib/librt.so.1 (0xb7263000)
libfreebl3.so => /lib/libfreebl3.so (0xb725f000)
If the binaries are identical, but ldd shows different dependencies, it must have something to do with the earlier dependencies requiring different libraries. Indeed, the output shows that the size of the libraries different between systems. Maybe you could make the system libraries identical by updating one or both systems?
– wallyk
I copied all the referenced libs from a different machine and now it works. – Danny
I'm trying to use NS2 but when I try to use nam.exe it'd not work! So is there other way to use nam.exe whitout using startX in CygWin?
thank you
Regards
``nam´´ is a GUI application (for X), and as such it requires X.
``nam´´ is using some X libraries:
$ ldd /usr/local/bin/nam
libXext.so.6 => /usr/lib/libXext.so.6 (0xb76b2000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7564000)
libnsl.so.1 => /lib/libnsl.so.1 (0xb7548000)
libdl.so.2 => /lib/libdl.so.2 (0xb7543000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb744f000)
libm.so.6 => /lib/i686/libm.so.6 (0xb7402000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb73e4000)
libc.so.6 => /lib/i686/libc.so.6 (0xb721a000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb71f7000)
/lib/ld-linux.so.2 (0xb76ec000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb71f3000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb71ec000)
I'm compiling 2 shared libraries ("A", "B") under Linux (Ubuntu 11)
The lib "B" is using exported function from lib "A" (linked statically with -lA)
But when I'm running ldd on "B" I just have*
linux-gate.so.1 => (0x004c0000) libc.so.6
/lib/i386-linux-gnu/libc.so.6 (0x00abf000)
/lib/ld-linux.so.2 (0x00679000)
I cannot see my "A" dependency !?
Strange, I was (almost) pretty sure ldd used to display ALL static dependencies !?
From man ldd
ldd - print shared library dependencies
There is no run-time dependencies for static libraries, since they were linked statically,
You need to link dynamically libA.so into libB.so, that is to build libB.so with something like
gcc -shared -o libB.so B*.pic.o -lA
(assuming no libA.a exist, only a libA.so)
And then you could use ldd libB.so to check that it does link libA.so
Look for example into most GUI libraries like /usr/lib/libQtGui.so.4 or /usr/lib/libgtk-3.so, e.g.
% ldd /usr/lib/libgtk-3.so
linux-vdso.so.1 => (0x00007fffe4cef000)
libgdk-3.so.0 => /usr/lib/libgdk-3.so.0 (0x00007f5a69c3b000)
libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f5a69a00000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f5a696c0000)
libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f5a694be000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f5a692bc000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f5a690b5000)
libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f5a68e92000)
libcairo-gobject.so.2 => /usr/lib/libcairo-gobject.so.2 (0x00007f5a68c8a000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007f5a689c9000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f5a687aa000)
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f5a68465000)
libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f5a68238000)
libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f5a67feb000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f5a67d4d000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f5a67b17000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f5a678c6000)
libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f5a676c3000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f5a674bd000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5a672b5000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f5a66fbe000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5a66d3b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5a66b1f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5a6679b000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f5a66587000)
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f5a66385000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f5a66176000)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f5a65f6d000)
libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f5a65d63000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f5a65b46000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5a65942000)
libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f5a656ba000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f5a65494000)
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f5a65291000)
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f5a65087000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f5a64e7d000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f5a64c65000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f5a64a44000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f5a6482e000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f5a64604000)
libffi.so.5 => /usr/lib/x86_64-linux-gnu/libffi.so.5 (0x00007f5a643f7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5a6a50e000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f5a641ba000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f5a63fb7000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f5a63db1000)