Hi Rush - I am a fan of the technique but don't know all of the ramifications of using it. I'll answer your questions as well as I can. Probably somebody smart from Apple will be able to correct me if I make an error :) On Mar 10, 2006, at 7:30 PM, Rush Manbert wrote: I was under the impression that when you link against a static lib, the granularity of code inclusion was the compilation unit. What I mean is that if I have a file called foobar.c with exported functions foo() and bar(), and I compiled it and linked it with junk.o and garbage.o to make a static library, then if I wrote a main.c that referenced bar() and linked against the static library, my linker output would essentially contain main.o and foobar.o.
Yes - this is inspectable with the "nm" command line tool. You should see above each section of symbols a line that indicates the source object file. If, instead of making a static library, you just make a single object file from foobar.o, junk.o, and garbage.o, then link that big object file with main.o, your linker output contains main.o, foobar.o, junk.o, and garbage.o. Question number 1: Is this true as far as you know?
Yes - one of the drawbacks, in my opinion. But I'm sure there are some advantages to this approach that are not springing to mind. Question number 2: If it is true, but you dead strip the linker result in both cases, do you come out with the same result? (Which would be, if I understand dead strip correctly, the contents of main.o plus whatever portion of foobar.o is required to implement bar()) I don't know. I would hope that in either case the dead stripping would cause un-exported symbols to be eliminated from the symbol tree, but in general I assume that Apple's dead code stripping doesn't work as well as we hope it would. It seems that it has been low on their list of priorities for the past several years.
Sorry I couldn't be more informative,
Daniel
|