GP32 multiple definitions problem

[Alex]

Hello!

I've decided to structure my program a little so I created several *.c files that contain my programs function in a sorted way.

Because I needed some global variables I created a *.h file, which is included in all *.c files to make this global variables accessible for all functions. To prevent redefintions i used

#ifndef ___example___ 
#define ___example___ 
.
.
.
#endif

That did it for compiling but when it comes to linking the different object files i get
"multiple definition of `i'" style error messages.

I wonder if it's possible to use the same header file in different *.c files. What makes me wonder is that gcc reports that linking error, when VC++ with the GP32 SDK compiles and links without errors and warnings.

I hope somebody can help me...Thx in advance.

Im using the devkitadv package and a slightly modified makefile of the example included.

h34r:

 

[Robster]

At a guess, I'd say you have something like

#ifndef __example__
#define __example__
int i;
#endif

which doesn't prevent redefinitions, because 'i' is still getting defined each time the header is included.

To get a global variable, you need to define it in one 'C' file, and then reference it in a header with

#ifndef __example__
#define __example__
extern int i;
#endif

The extern tells the compiler not to worry about not finding the variable, because the linker will fix it up later.

Not sure why VC++ wouldn't give an error for that, maybe it's something to do with pre-compiled headers?

 

[Alex]

Thanks for help.

I feared it would end in using extern... :blink:

I declared all global variables im my header files extern and made another header file that contains the real definition of all global variables. This is included only once, so that it will appear in only one object file. That works for me.

Thinking about that problem now, it is clear that without extern it would not work. Merging three object files into one linkfile the linker gets three identical variables and doesn't know which one to use.

It would be nice if there would be an linker option to take the first occurence of an variable as the definition and treat others as extern refering to the first occurence. That would avoid this complicated headerfile contructions. Perhaps that's what VC++ linker does, I tried it with PCH off, but it linked without problems. Who knows...Not Me...

h34r:

 

[count zero]

wouldnt it be easier to create several *.h files to structure your program?
i normaly do it this way.

then there is an easy solution for the variables.
i have one vars.h file with all vars that should be accesible from all my routines.

in the main (*.c) file then it says (for example):

#include "vars.h"
#include "grx.h"
#include "save_data.h"


so the vars declared in vars.h are usable in the main *.c file an in all the include files standing AFTER the #include "vars.h" (so its important that vars.h is the first u include)

if i got the problem wrong SORRY!!

 

[Alex]

I thought about it, too...

Putting all functions in the header files would solve the problem, too, because only one object file is created and the variables are only defined once.

I didn't do it that way because then you have to be careful with the include order of the header files. My header files contain some function related variables and the function declarations. Putting the code in the header file it would get troublesome to call the functions from other header files, because include order is important.

 

[count zero]

hmmm...

yes i hate this too.
u wan't to clean up ur code end it ends in the situation that some function isn't able to call another!

But when i prog right from the beginnig using *.h files (and not cleaning up the code when it's neraly ready) i mostly get it to work this way.

but probably my progs aren't that complicated than ur's.

sorry i couldn't help.

i wish u good luck solving ur problem!

 

[generalnmx]

However, sorting out your include order also helps prevent over-use of extern (which can be hard to follow sometimes) and just general code bloat. It may be annoying, but making up a design tree can be very helpful at times.