tags:

views:

110

answers:

5

For example, how to get the version of /usr/lib/libz.a? It will be great if other useful information such as compiler/arch etc. can be fetched.

The reason I want to know this is that gcc always say it ignored the libz I offered in command line when I compile my program and linked with specific versioned libz. gcc think the /usr/lib/libz.a is a proper one.

+5  A: 

C libraries do not have on their own a versioning system. At best, there is a symbol in the library that tells it.

zneak
+1  A: 

On Mac OS X there's otool, which tells you a bunch of things, including version and arch (though lipo -info is probably better for arch). Example:

$otool -L /usr/lib/libz.dylib 
/usr/lib/libz.dylib:
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)

otool -L lists all libraries the library or executable ("object file") links to, but the first line is the "id" of the object file itself, which includes the version number. This is probably Mac-only though.

crimson_penguin
+1  A: 

If it has a symbol for version # then you can use strings -a file_name|grep 'the version symbol' . If you got the library as part of a rpm then perhaps you can use the rpm build number to get a version (not exactly the library version but at least some form of numbering.)

CoolBeans
Sorry, grep what, please?
solotim
Ha! That's why I said if it has a symbol for a version number. For example in our internal libraries we use something like @#version string to grep for the version number. I am not sure what this particular static library uses or if it uses any at all. If you just do strings and pipe it to a text file then you should be able to see all the symbols in the lib and then perhaps look for something like ver or version ... as other have noted it's not easy. Sorry I wish I knew a better answer than this. :-)
CoolBeans
Thanks, I can find the compiler info by your method whatsoever.
solotim
+2  A: 

Linux/Unix Elf-specific answer:

Library archives with the .a extension are an ar archive (a little like a tar or an uncompressed zip, modulo a few features), which contains nothing more than the original object files packed together. There is rarely any extra metadata in these files. You are unlikely to find any information about the compiler unless it stored that information in the original .o files. You can view the contents of an archive with the ar command:

ar -t /usr/lib/libz.a

Or the objdump command:

objdump -a /usr/lib/libz.a

Shared object files (.so) and executables are a different story. Using the readelf and dumpelf commands from elfutils, you can extract metadata about the shared object, including its canonical name, what libc it was built for, which toolchain built it, and so on. See man readelf and related pages for details.

greyfade
A: 

On Linux (like) systems the version is usually in the name.
This is sort of hidden as the libraries you link against are symbolically linked to a specific version:

> ls -l /usr/lib/libncurses.dylib
lrwxr-xr-x  1 root  wheel  20 Feb 28 16:08 libncurses.dylib -> libncurses.5.4.dylib

So when you link against -lncurses the compiler actually sticks a reference to libncurses.5.4 into the application. If you look at the symbol table in the application you will see that it actually stores very specific version info for each lib not the generic version that it was linked against.

Martin York