ldd returns different information on different systems
Dr. Zimmermann
If I use 'ldd' on a dynamically linked binary, I got different
information (= libnames) on different systems(*).
Can someone shed some light upon this mystery ?
Roger
(*) All systems runnning linux with gcc and binutils with different
version numbers.
--
Dr. Roger Zimmermann *** Institute of Physiology, Hamburg
Martinistra/3e 52 D-20246 Hamburg Tel.: /40 42803 5351
-------------------------------- Fax.: /40 42803 4920
R.Zimmermann=at=Uke.Uni-Hamburg.de // roz=at=snafu.de
PGP-ID: Roger Zimmermann
KeyPrint=83 16 D1 82 06 71 16 60 6F 61 95 65 BB CA 02 E0
Paul Pluzhnikov
> Can someone shed some light upon this mystery ?
Why is it a mystery?
On Linux, socket(3) is in libc. On Solaris it is in libsocket,
which in turn dynamically depends on libnsl and other libaries.
Thus, any network program on Solaris will have libsocket and libnsl
in ldd output, while on Linux these 2 libraries do not exist (their
functions are in glibc).
> (*) All systems runnning linux with gcc and binutils with different
> version numbers.
The same version of gcc and the same version of all libraries?
If not, the answer is: because different versions "package" things
differently (just like Solaris vs. Linux example above).
Cheers,
--
In order to understand recursion you must first understand recursion.
Dr. Zimmermann
> "Dr. Zimmermann" <R.Zimm...@uke.uni-hamburg.de> writes:
>
> > Can someone shed some light upon this mystery ?
>
> Why is it a mystery?
>
> On Linux, socket(3) is in libc. On Solaris it is in libsocket,
> which in turn dynamically depends on libnsl and other libaries.
>
> Thus, any network program on Solaris will have libsocket and libnsl
> in ldd output, while on Linux these 2 libraries do not exist (their
> functions are in glibc).
>
OK, but lets have a look only at linux systems (see below).
>
> > (*) All systems runnning linux with gcc and binutils with different
> > version numbers.
>
> The same version of gcc and the same version of all libraries?
> If not, the answer is: because different versions "package" things
> differently (just like Solaris vs. Linux example above).
This is the real example of a third-party compiled program:
At system 1:
libpopt.so.0 => /usr/lib/libpopt.so.0 (0x4001f000)
libqt.so.2 => /usr/lib/qt-2.3.0/lib/libqt.so.2 (0x40025000)
libstdc++-libc6.1-2.so.3 => /usr/lib/libstdc++-libc6.1-2.so.3
(0x406dd000)
libm.so.6 => /lib/libm.so.6 (0x40725000)
libc.so.6 => /lib/libc.so.6 (0x40748000)
libsocket.so => not found
libbind.so => not found
libX11.so => /usr/X11R6/lib/libX11.so (0x40867000)
libXext.so => /usr/X11R6/lib/libXext.so (0x4095f000)
libjpeg.so => /usr/lib/libjpeg.so (0x4096d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libstdc++.r4.so => not found
libroot.so => not found
libnet.so => not found
libdl.so.2 => /lib/libdl.so.2 (0x4098c000)
At system 2:
libpopt.so.0 => /lib/libpopt.so.0 (0x40027000)
libqt.so.2 => /usr/lib/libqt.so.2 (0x4002d000)
libstdc++-libc6.1-2.so.3 => not found
libm.so.6 => /lib/libm.so.6 (0x4054a000)
libc.so.6 => /lib/libc.so.6 (0x4056e000)
libGLU.so.1 => /usr/X11R6/lib/libGLU.so.1 (0x4069d000)
libGL.so.1 => /usr/X11R6/lib/libGL.so.1 (0x406bf000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40726000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4073d000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4074c000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40837000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40840000)
libXft.so.1 => /usr/X11R6/lib/libXft.so.1 (0x40857000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4087d000)
libmng.so.1 => /usr/lib/libmng.so.1 (0x4089f000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
(0x408e3000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4092b000)
libdl.so.2 => /lib/libdl.so.2 (0x40942000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40946000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40999000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4099e000)
libz.so.1 => /lib/libz.so.1 (0x409db000)
1) Which of these is true ?
2) Is this probably a bug in one of the linux installations ?
>
> Cheers,
> --
> In order to understand recursion you must first understand recursion.
Cheers, Roger
mike burrell
Why can only one be true? The system that can't find some of the libraries
obviously won't be able to load the binary, but they're both "true".
> 2) Is this probably a bug in one of the linux installations ?
If you consider not having a library installed a bug....
Perhaps this is a misunderstanding as to how dynamic linking works?
--
/"\ m i k e b u r r e l l
\ / ASCII RIBBON CAMPAIGN mik...@shaw.ca
X AGAINST HTML MAIL,
/ \ AND NEWS TOO, dammit
Paul Pluzhnikov
> 1) Which of these is true ?
Huh? Both are. All "ldd" does is tell runtime loader:
load all the libraries, but don't execute any code.
> 2) Is this probably a bug in one of the linux installations ?
Didn't the "third-party" tell you what system they compiled this
executable for?
If they did, and you are not running *on that specific* release,
then you are violating their assumptions, and all bets are off.
If you are running on their release, or if they told you that it
ought to work on other releases/distributions, then you've just
proven them wrong, and they need to rethink their build/distribution
strategy. [It is surprizingly difficult to make a C++ executable that
"just works" on an arbitrary distribution].
> At system 1:
> libsocket.so => not found
This looks very "fishy" -- I've never seen a linux system with
libsocket.so ...
> At system 2: [...]
> libstdc++-libc6.1-2.so.3 => not found
[...]
> libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
This is *also* a big problem -- you have pulled two (perhaps
incompatible) versions of libstdc++. Expect "undefined" behaviour
to strike soon ;-(
Jens Thiele
> Paul Pluzhnikov wrote:
>
>
>>"Dr. Zimmermann" <R.Zimm...@uke.uni-hamburg.de> writes:
>>
>>
>>>Can someone shed some light upon this mystery ?
>>
> This is the real example of a third-party compiled program:
>
> 1) Which of these is true ?
>
> 2) Is this probably a bug in one of the linux installations ?
>
this is because ldd does not only print the libraries your dynamically
linked binary (directly) depends upon - but also the dependenices of the
libraries
something like
objdump -x foofile |grep lib
might help
karme
PS: the dependencies listed for system 1 look strange
Dr. Zimmermann
> >
> > 1) Which of these is true ?
>
> Why can only one be true? The system that can't find some of the libraries
> obviously won't be able to load the binary, but they're both "true".
>
> > 2) Is this probably a bug in one of the linux installations ?
>
> If you consider not having a library installed a bug....
>
> Perhaps this is a misunderstanding as to how dynamic linking works?
>
Hi,
I was some days absent, so ...
I still not understand, how does 'ldd' figure out the linked libraries.
For me, it would be understandable, if the binary is linked on one system
against e.g.
libXext.so.6 and on the other against libXext.so
I don't understand, why there are libraries with specific functionality (i.e.
libGLU.so.1)
link-referenced on one system but not on the other. In my understanding, there
should be at least
some Message similar to:
libGLU.so => not found
on system 1 or equivalent with another library vice versa ?
It seems that 'ldd' here choose some kind of alternative with complete
different functionality ?
Still lumbering in the darkness ...
Paul Pluzhnikov
> I still not understand, how does 'ldd' figure out the linked libraries.
Here is a *simplified* description of the process:
- first it looks at the a.elf dynamic section (you can see what's
in the dynamic section with "objdump -p a.elf" of "readelf -d
a.elf") to find any NEEDED libraries.
- then it tries to find each one of them, looking
in the a.elf RPATH (also from dynamic section) directories,
in your LD_LIBRARY_PATH directories and
in the directories specified in /etc/ld.so.conf ("man ldconfig").
[There may be other places it looks for libraries as well].
- for each library found, it repeats the process (libraries can have
dependencies on other libraries).
It is true that the *initial* set of needed libraries is identical
on both of your machines (since the list comes from the same
executable).
But after that, it could easily diverge: if libFoo.so on system-A
has libBar.so as a dependency, but libFoo.so on system-B doesn't.
Dr. Zimmermann
> Here is a *simplified* description of the process:
>
> - first it looks at the a.elf dynamic section (you can see what's
> in the dynamic section with "objdump -p a.elf" of "readelf -d
> a.elf") to find any NEEDED libraries.
>
> - then it tries to find each one of them, looking
> in the a.elf RPATH (also from dynamic section) directories,
> in your LD_LIBRARY_PATH directories and
> in the directories specified in /etc/ld.so.conf ("man ldconfig").
> [There may be other places it looks for libraries as well].
>
> - for each library found, it repeats the process (libraries can have
> dependencies on other libraries).
>
> It is true that the *initial* set of needed libraries is identical
> on both of your machines (since the list comes from the same
> executable).
>
> But after that, it could easily diverge: if libFoo.so on system-A
> has libBar.so as a dependency, but libFoo.so on system-B doesn't.
OK, thanks for that explanantion. So to conclude, the NEEDED libraries
(from "objdump -p myprog") should be similar for all my linux systems
as far as I understand.
THNX, Roger
Paul Pluzhnikov
> OK, thanks for that explanantion. So to conclude, the NEEDED libraries
> (from "objdump -p myprog") should be similar for all my linux systems
> as far as I understand.
Given 2 copies of the same executable, the lists of NEEDED libraries
(from the dynamic section of the executable itself) are not "similar",
they are *identical* by definition.