1. Forum
  2. Usenet
  3. COMP.SYS.ACORN.PROGRAMMER

  • Trouble linking C

    From news@sprow.co.uk@21:1/5 to use...@garethlock.com on Thu Mar 26 07:06:51 2020
    On Thursday, 26 March 2020 13:57:32 UTC, use...@garethlock.com wrote:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From usenet@garethlock.com@21:1/5 to All on Thu Mar 26 06:57:32 2020
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From usenet@garethlock.com@21:1/5 to All on Thu Mar 26 08:08:38 2020
    Ok... Got it... Crashes when run though, need to sort that out...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From usenet@garethlock.com@21:1/5 to All on Thu Mar 26 07:56:01 2020
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nick Roberts@21:1/5 to news@sprow.co.uk on Thu Mar 26 17:22:47 2020
    In message <b5607488-bb02-416d-a511-1c2a90a28d0a@googlegroups.com>
    news@sprow.co.uk wrote:

    On Thursday, 26 March 2020 13:57:32 UTC, use...@garethlock.com wrote:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)