🚀 go-pugleaf

In article <C1A0IC.I0G@icon.rose.hp.com> wes@hpsmo100.rose.hp.com (Westley) writes:

[problems with declaring variables in header files omitted]

>I have seen a similar behaviour ONLY when both files (foo.c and bar.c) are
> included in the same 'project'.  Turbo C will completely compile all files
> related by the project list and then try to link them.  If you have an
> #include that declares a variable, it will be declared in ALL files that
> refer to that #include.  Then the link process will find multiply declared
> variables.  
>One way to avoid this is to NOT have any variable declarations in generic
> #include files.  In other words, declare any variable IN each file, not in
> an #include.  ONLY one of the files will need to do the actual declaration,
> the others will refer to that declaration with 'extern' put in front of
> their declarations.
>The 'project' option in Turbo C is pretty neat, but can be dangerous if you
> don't understand it completely (as I did the first few times I tried to use
> it).  Good luck with your project.
>
>	Westley
>	wes@hpsmo100.rose.hp.com

Another way to avoid this, in C, not C++, is to set the "generate COMDEFs"
option to on.  When a non-initialized variable is in a header file, every
module which includes that header is going to try to allocate space for it
in its OBJ which generates a PUBDEF.  The COMDEF allows the linker to decide
what to do about the variable and thus can help.  Note though, that
the Borland will not genrerate COMDEFs when it is compiling a C++ module.

This really isn't the fault of the Project concept, since any program
that does this is going to fail in the linking, whether via a project make
or via the command line linker.


Regards,




Jeff K

-- 
National Instruments - I work for them, not speak for them.