Let's say we have a some library compiled into .a file. After that this library is linked with other code into some executable file .exe. Size of .a file is 6Mb while this size of .exe file is 3Mb. Obvious explanation of this is that linker has thrower out unused code from the library. What I want to know is the real library's code footprint in final executable file.
A:
A library has implementation of a lot of functions. An exe use some of there. The liker add in exe only the code of functions which exe use.
Oleg
2010-06-19 12:03:19
That's what I've said "Obvious explanation of this is that linker has thrower out unused code from the library"
ashrugger
2010-06-19 12:16:17
But it MUST be so by design if you use a LIB file. If use have a large LIB abd use only one function from the LIB, then only one OBJ from the LIB with it's dependencies will be added to EXE. On the other side if you place a lot of functions inside one OBJ file and link it to your application the whole OBJ will be added to the EXE. With respect of additional switches one can remove unused functions from the imported OBJ file.
Oleg
2010-06-19 16:34:29
For example in http://en.wikipedia.org/wiki/Static_linking you can read following "With static linking, it is enough to include those parts of the library that are directly and indirectly referenced by the target executable (or target library). With dynamic libraries, the entire library is loaded, as it is not known in advance which functions will be invoked by applications. Whether this advantage is significant in practice depends on the structure of the library."
Oleg
2010-06-19 16:45:42
+3
A:
Check out the linker options. Linkers usually have an option to generate a map file. Which is a list of functions linked into the final image and where they came from. Sounds like you are using gcc, use the -map option.
Hans Passant
2010-06-19 12:13:27