How does compiler use lib file?

I am curious about how c/c++ compiler analyse lib 开发者_如何学运维files ? I mean say I create a library containing some classes, I am using that library in my main program. How does compiler know what class names are there in that library. Of course that information is present in binary format, I want to use that functionality in my program, to be specific I have a binary lib file and I want to know all classes and properties/functions present in that lib file.

Is it possible ? If compiler can do that why can't some library ?

thanks for any clue

The compiler doesn't do what you are suggesting, but the linker does.

The compiler knows the information it needs from the header files that are included relating to the lib files.

The linker then puts together the declarations you are including and the lib file along with its other object files.

It is probably possible to get the information from the .lib file by decompiling it for example, but this is a lot of work and probably not what you're looking to do.

Depending on your system (I know this is true for .a files on Linux, not so sure for windows) library files are just an archive file (thus the .a) containing a bunch of normal object files. Think tar or zip and you will be darn close. The linker more or less just extracts the files form the archive, tacks them in the command line and links everything together (It doesn't actually do that because it has some special rules like only getting things lazily, but it's close enough for the topic at hand).

If you want to know what inside, get library tool (IIRC ar on Linux) and dig into the docs. Even money says the tool will be able to extract the object files and from there you can use standard tools to extract their contents.

Typically, a .a library is just an archive, which itself contains a pile of object files. These commands are done on Linux, it will vary between platforms. You can usually examine the basic contents of an archive by running nm libxxx.a

/usr/lib> nm libc.a | head -10
init-first.o:
         U abort
         U _dl_non_dynamic_init
0000000000000000 T _dl_start
         w _dl_starting_up
         U __environ
         U __fpu_control
         U __init_misc
0000000000000004 C __libc_argc

The nm manpage has plenty of detail on what the output means.

The ar command can extract individual files for you e.g.

~/tmp> ar x libc.a init-first.o
~/tmp> file init-first.o
init-first.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped

As you can see above, the objects here are ELF format, so for the complicated bit of what you were asking, what you really need is something that can examine ELF binaries. Linux usually ships with the command readelf which will give a lot of information at the command line:

~/tmp> readelf -s init-first.o
Symbol table '.symtab' contains 19 entries:
Num:    Value  Size Type    Bind   Vis      Ndx Name
 0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
 1: 00000000     0 SECTION LOCAL  DEFAULT    1
 2: 00000000     0 SECTION LOCAL  DEFAULT    3
 3: 00000000     0 SECTION LOCAL  DEFAULT    4
 4: 00000000     0 SECTION LOCAL  DEFAULT    5
 5: 00000000     0 SECTION LOCAL  DEFAULT    6
 6: 00000000    11 FUNC    GLOBAL DEFAULT    1 _dl_start
 7: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND abort
 8: 00000010   133 FUNC    GLOBAL DEFAULT    1 __libc_init_first
 9: 00000000     0 NOTYPE  WEAK   DEFAULT  UND _dl_starting_up
...

There is a library libelf which very probably does what you want and accesses this information programatically. I've never used it, as I've always got the information I needed from the command line tools available.

http://directory.fsf.org/wiki/Libelf

To amplify Brian R. Bondy's answer by the time the code has hit the linker, the most useful information to humans has been stripped out. For example, you can extract the following information from an object file (library):

class SomeClass implements SomeInterface {
    int get(class &otherClass c, float x);
    bool reallyCoolMethod(int x);
    ...
}

Which is truly less than helpful. The library documentation should explain why you would want to use it and how; if the library isn't so documented, you might want a better library.