Mail Archives: djgpp/1998/11/05/10:25:24
On Thu, 5 Nov 1998 09:46:29 +0200 (IST), Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> wrote:
>
>On Thu, 5 Nov 1998, Mapson wrote:
>
>> IOW, if I have 25 functions in a lib, and my program only needs 2 of
>> them, only the object code for two functions is extracted from the
>> lib.
>
>This is correct. But please note the cricual gotcha: ``only needs 2
>of them'' must mean that the program doesn't reference any of the other
>23 functions in any way in the code.
>
>For example, if the code says something like this:
>
> if (they_want_function_number_23)
> function_number_23 ();
>
>then the linker will link in function_number_23 even if this condition
>never fires at run time.
I will study this closely in the code I'm constructing.
Given past experience, I trust your knowledge of this efficient manner
of libs in DJGPP. But I must say that I am getting some conflicting
information on it from different people- probably because different
compilers do this differently. A majority of opinions seem to think
that all the object code of libs gets dropped in in a link. In the
past I have wondered if it works by specific object modules in the
archive. That is, if I have 7 different ".o" files comprising a lib, a
call requiring code from one ".o" file simply takes that entire ".o"
file's worth of code.
Funny that all of my books (and the ones I look at in bookstores ;-) )
just sort of skip the whole issue of creating libs in general- perhaps
it is too compiler dependent.
>> Problem with my theory: the final executables made with the libs
>> are *considerably* (20%) larger than the same programs with the raw
>> source code (all 25 functions) built in!
>
>Did you strip the executables? If not, the overhead of the debug info
>in the executable completely overshadows the actual amount of code.
The reason I don't strip these particular executables is because my
understanding of stripping is that it removes debugging information.
Since I am automatically constructing these executables from rules
contained in user's "source files" (written in my pseudo-language), I
am (in this stage) still interested in any crash/error junk their
programs spew.
Still wondering what the overhead in linking with libs is, though. I
am not one of those that complains about DJGPP executables being too
big- that's a lame complaint IMHO. What I am curious about here is not
the sheer size of these particular executables, but *that they are
bigger* than the same with the lib code built directly directly in. I
think I am happy to live with that (what is 180k versus 220k- not a
big issue)- but right now I am wondering if it is something in my
techique that bloats them. Perhaps the way I call ar inserts extra
"stuff"? ( ar -rvs ). I am more curious than alarmed.
<...>
Thanks for the preprocessor tips for including extern vars. I'm
gathering that I need to be a little more imaginative than I generally
allow myself with preprocessor stuff. Interesting and useable
solution- thanks.
>> Problem: I don't understand why this is true with variables and not
>> functions- that is, the declared functions certainly don't cause any
>> problem.
>
>There's a difference between _declaration_ and _definition_. This is a
>declaration of a variable:
>
> extern int foo;
>
>This is a definition of the same variable:
>
> int foo;
>
>This is a declaration of a function:
>
> extern int foo (void);
>
>This is a definition of the same function:
>
> int foo (void) {}
>
>Try to put the last definition in a header and include that header in
>more than a single source file, and the linker will yell bloody murder.
Well put. Thanks.
>> theory is that the variables, being global, all are given a default
>> compiler value ( globals are set to zero by default, right?), and that
>> is why the multiple declaration errors occur- it is as if each
>> occurance, rather than a declaration, is also a value assignment.
>
>No, that's not the real reason. The *real* reason is that a definition
>causes the compiler to instruct the linker to assign an address for that
>variable, and the linker will complain when it is required to assign two
>different addresses to the same symbol.
>
>In contrast, a declaration only causes an unresolved external symbol to
>be emitted by the compiler (which the linker resolves at link time, by
>putting an address there).
Another keeper for my personal FAQ.
I've certainly have gotten some great help from you in the past week.
Thanks tremendously.
- Raw text -