>Part of my difficulty was that I didn't expect the CodeWarrior linker to be as
>ruthless as it actually is. When one explicitly specifies that a code module is to
>be included in a target, I expect the linker to put it in the executable, whether or
>not anything else actually depends on it.
Here we disagree. The old Think C linker did this. I hated it. I want _small_
executables.
It discourages the development of shared source files, because I don't want to add 10K
to
my executable's size just to call one function. Much better to copy the function out
of the
"shared" source into my own project, keeping the target small, but destroying any code
sharing.
>But CW evidently does not do so, instead determining the contents of the executable
>as the transitive closure of a dependency tree rooted in the main function, in the
>way that traditional linkers handle libraries. Even more surprising is the evident
>fact that the CW linker is not even limited to just including or excluding a whole
>code module -- it will include some *functions* out of a code module and leave out
>others, if there are no references to them.
This, to my mind is what a linker _should_ do. It should include all the code
that is necessary for the program, and no more.
What's the point of trying to optimize the size of your code, if the linker is going
to leave 30K of unreachable code in your final executable?
>I would have gotten to the root of my problem a lot faster if I had just looked at
>the sizes of the .prc files -- the ones in which my original problem occurred were
>about 13 times the size of those in which it did not occur! By turning off one last
>line of code in the main module, I unknowingly removed a critical dependency, causing
>the linker to omit 90-odd percent of the rest of the modules, including the one with
>the offending static initializer.
When you say "static initializer", do you mean a global object that contains a
constructor?
(or is initialized to a value) such as:
BytePtr gBar = NULL;
Or do you mean a static object of non-global scope, like this:
void Foo ( ) {
static int twelve = 12;
}
In the second case, the variable "twelve" will not be initialized until the first time
that
Foo () is called.
>Strictly speaking, it is not correct for a C++ linker to use this sort of heuristic:
>the programmer should be able to specify that a particular module is to be included,
>exactly *because* he needs the side-effects of a static initializer in that module.
If you include a module that contains global variables, the globals should be included
in
the executable, and all code needed to construct and destruct them as well.
Could you post an example of what you were doing (because I don't think I understand).
Thanks!
-- Marshall
"The era of big government is over."
Bill Clinton, State of the Union Address, January 23, 1996
Marshall Clow Adobe Systems <mailto:[EMAIL PROTECTED]>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
