On 15 Apr 2002, Mike Noyes wrote:
> Everyone,
> I'm still unable to decipher the libc minor version from output
> generated by ldd. All of our packages that I have looked at so far use
> libc major version 6. The output below is from KP's squid-2 package. He
> states that it was compiled with glibc 2.1.3. How can I verify this from
> the output below?
You can't, unfortunately. Your goal is a hard one to reach, at least for
me.
Your original question to which I responded with the "ldd" solution did
not specify specifically the glibc versioning problem. Sorry I didn't
read between the lines.
> Output generated on shell.sf.net:
>
> mhnoyes@usw-pr-shell2:~$ ./ldd-ver.sh squid-2.lrp
> <snip>
> libc.so.6 => /lib/libc.so.6 (0x05b95000)
> libc.so.6 => /lib/libc.so.6 (0x0729a000)
> libc.so.6 => /lib/libc.so.6 (0x074f0000)
> libc.so.6 => /lib/libc.so.6 (0x0847b000)
> libc.so.6 => /lib/libc.so.6 (0x091dc000)
> libc.so.6 => /lib/libc.so.6 (0x0c92d000)
> <snip>
>
> Also, the output generated by ldd varies depending on the machine I run
> it on.
>
> Output generated on my local machine:
>
> [mhnoyes@galileo leaf]$ ./ldd-ver.sh packages/squid-2.lrp
> <snip>
> libc.so.6 => /lib/libc.so.6 (0x40028000)
> libc.so.6 => /lib/libc.so.6 (0x40053000)
> libc.so.6 => /lib/libc.so.6 (0x40073000)
> libc.so.6 => /lib/libc.so.6 (0x400a0000)
> <snip>
By looking at what the application requires, you are typically limited to
the major version number because that is how the shared library
conventions work.
However you are encountering (again? this has been discussed before here)
the classic problem that the glibc programmers created in their effort to
handle binary compatibility. I have yet to see a cohesive argument for
their strategy... I don't even know if locking in the minor versions was
part of their plan. Essentially they conspire to keep libc.so.6 filename
fixed, and keep replacing it with versions that have new functions tacked
onto the end of the libraries... with similar function names
differentiated by adding a GLIBC_2.1.3 or whatever to the name.
To see this, compile a hello-world program with "-g" and run "nm" on the
executable. Unfortunately, most LEAF executables are stripped, so the
symbol names are gone. "objdump" can extract a little information from
the file, but I haven't been able to determine how to distinguish the
library versions from each other.
One possible avenue would be to learn what the offset of the last function
in glibc2.0 was, and if any of the fixup offsets in an executable was
greater than that value then that executable would be expected to break
with glibc2.0 (when the program calls it, it would execute undefined
opcodes). This might be extended to handle various glibc versions, but I
suspect it would be uncomfortably closely tied to specific compilations of
glibc.
BTW: apparently, the number in parentheses displayed by ldd is the process
space address at which the first byte of the library would be loaded. I
think this is what the fixup offsets in the executable would be added to
to get the locations of the library functions. It would probably be
specific to each compilation of that program, and would have no direct
value in determining the library version.
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...2k
---------------------------------------------------------------------------
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
