Re: Is "undefined reference" the same as "unresolved external symbol"?

[Bernd Jendrissek <bernd at bpj-code dot co dot za>]

On Thu, Jan 15, 2015 at 2:11 AM, emkessler <ldgn86a@yahoo.com> wrote:
> I am currently converting a computer game project from Microsoft Visual
> Studio to GCC. Under Microsoft Visual Studio it builds and runs correctly.
> Under GCC it compiles but does not link.
>
> The source file "Battlefield.cpp" contains the line:
>
> extern bool bRemoveOrganFromBeast, bCarryingNarulung, g_bManWillBeAttacked;
>
> The source file "Enemy.cpp" contains the lines:
>
> bool g_bManWillBeAttacked = false, g_bMakingGift = false, g_bGiftAccepted[2]
> = { false, false }, g_bEnemyMoveCallback = false;
> #pragma message("The symbol \"g_bManWillBeAttacked\" has been defined.")
>
> The compiler output contains the line:
>
> ../../Human/Enemy.cpp:23:72: note: #pragma message: The symbol
> "g_bManWillBeAttacked" has been defined.
>
> The linker output contains the line:
>
> Battlefield.o:Battlefield.cpp:(.text+0xcd): undefined reference to
> `g_bManWillBeAttacked'
>
> and ends with the lines:
>
> /usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../i686-pc-cygwin/bin/ld:
> Battlefield.o: bad reloc address 0xd in section
> `.text$_ZN7CListOfI8ISoldierEC1Ev[__ZN7CListOfI8ISoldierEC1Ev]'
> /usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../i686-pc-cygwin/bin/ld: final
> link failed: Invalid operation
> collect2: error: ld returned 1 exit status
>
> Questions: (1) Does "undefined reference" here mean the same as "unresolved
> external symbol" does under Microsoft Visual Studio?

Yes, it's the same.

> (2) How can that happen when the symbol is obviously defined?

It could happen if both source files are compiled into libraries, and
the library order doesn't allow one to see definitions in the other.
On Unixy platforms, libraries don't see "backward" up the link line.
For example, if your final link is something like

  gcc program.o -lmap -lunits

then if your variable is defined in libmap, and libunits uses it, it
can't resolve the reference. To fix this sort of problem, invert the
order or libraries, or if it's a circular dependency, repeat the
earlier library after the one that uses symbols defined in it. In my
example, program.o can use any symbols defined in libmap or libunits,
and libmap can use any symbols in libunits, but libunits canot use
symbols from libmap.