Discussion:
Trouble linking C
(too old to reply)
u***@garethlock.com
2020-03-26 13:57:32 UTC
Permalink
Been spending the time at home re-writing Brix in C. Having trouble linking due to missing symbols. The variables involved are declared as extern int32 (typedef'd as long) and contain the addresses of the graphics data... gfx_sprite, gfx_digits and gfx_chars. There is a fourth, gfx_bank, which always points to one of the other three. They are given a value by the routine that loads the graphics.

I first tried declaring these in the main h file which all C files include, then the main C file, then with the graphics routines. No errors mentioning these are generated when compiling, however when trying to link the objects (.o files) together to generate an executable, no matter which order I link everything in or where I put the declarations I keep getting these errors referring to them as missing symbols. BTW I'm using the Acorn DDE supplied with NutPi (cc v 5.71 Aug 2014)
n***@sprow.co.uk
2020-03-26 14:06:51 UTC
Permalink
Post by u***@garethlock.com
Been spending the time at home re-writing Brix in C.
The variables involved are declared as extern int32
Are they declared somewhere once (and only once) without extern?
If not - that's the problem.

The extern's tell the compiler that a variable exists elsewhere and of what type, and the linker fixes up the references to it. But one of the source files needs to have the variables without extern so that the variable exists in memory,
Sprow.
u***@garethlock.com
2020-03-26 14:56:01 UTC
Permalink
Yeah... That's being done with int32 gfx_sprite = gfx_load(<filespec>) from the main C file... That's the bit I don't understand.
u***@garethlock.com
2020-03-26 15:08:38 UTC
Permalink
Ok... Got it... Crashes when run though, need to sort that out...
Nick Roberts
2020-03-26 17:22:47 UTC
Permalink
Post by n***@sprow.co.uk
Post by u***@garethlock.com
Been spending the time at home re-writing Brix in C.
The variables involved are declared as extern int32
Are they declared somewhere once (and only once) without extern?
If not - that's the problem.
The extern's tell the compiler that a variable exists elsewhere and
of what type, and the linker fixes up the references to it. But one
of the source files needs to have the variables without extern so
that the variable exists in memory,
That's not quite true - declaring a variable as extern, does, as you
say, simply tell the linker that the variable exists. But if you use:

extern int fred = 0;

then that is taken to be the defining point of fred and hence fred is
present in the compiled object file and the linker is happy.

The main point is that is that one of the source files needs to contain
a defining point for the variable, not that one of them shouldn't have
"extern".
--
Nick Roberts tigger @ orpheusinternet.co.uk

Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.
Loading...