Mail Archives: djgpp/1998/11/05/03:20:37
Mapson <mapson AT mapson DOT com> wrote in article
<364132d1 DOT 31058536 AT news DOT cis DOT yale DOT edu>...
> I have posted a similar question to a C/C++ newsgroup, but it has
> occured to me that one of my questions (executable bloating) may
> relate directly to the fact that I am using DJGPP and the "ar" utility
> to make libs (".a") files from .o files.
>
> I need to make two libraries for the project I am doing now- one main
> one and one created out of user hardware information. The system
> works, but here are some questions I have about it.
>
> First of all, one of the reasons I decided to make libs instead of
> just putting the code directly in my source files is that I thought
> libs were a way of accessing only what is needed in a given program.
> 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. 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! Even if my theory was wrong,
> I'd have expected them to be close in size... why are my programs so
> much larger by linking with the libs?!
>
I do not know. Remember that You have to use one .c files for each function
if you want to be able to retrive the single function out of a lib. If all
the function are on the same file, you compile on a single .o the will be
included in the lib as a single entity: whenever you reference a symbol
defined in this .o, the linker extract and link the whole .o
> Secondly, include files have taken on a new significance with these
> libs. I used to keep my global variables in my header files- but in
> the case of these libs, they only cause "multiple declaration" errors
> later on- even when I uses the standard "#IFDEFINED _THIS_LIB_ ... way
> of only including things once. Solution was to pull all variables out
> of the include files, put them in the source files for the libs.
> 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 is something I am missing here in my understanding, and
> none of my books address this sort of stuff directly. Presently my
> 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.
> Wrong?
>
Do You declare global variables as 'extern' ?
Your include file should declare variables as 'extern': this do not reserve
space for the symbols but say to the compiler that somewhere exist an
istance of these variables. The variables will be allocated in the
implementation file only (same declaration, without 'extern'). If you omit
the 'extern' keywords the compiler create a new symbol for each source file
including the header and the linker will find more symobls with the same
name. If you do not want to write two times the variable declaration (one
in the header - extern - and one in the source) You can use the following
declaration in Your header:
#ifdef _THIS_LIB_H_
#ifndef _THIS_LIB_PLEASE_ALLOC_VARS
#define _THIS_LIB_IMPORT extern
#else
#define _THIS_LIB_IMPORT /* dummy */
#endif
....
_THIS_LIB_IMPORT int var1;
....
....
#endif // _THIS_LIB_H_
The implementation source file:
#define _THIS_LIB_PLEASE_ALLOC_VARS // Really allocate the vars...
#define "this_lib.h"
The user:
#include "this_lib.h" // use extern in the declarations
- Raw text -