Linking against libcommon.a fails

[jdoran]

If you comment those externs out and recompile, you will either see where they are used, or learn that they are not needed.

A search of the source code will also show the usages. For example: spdat.cpp has three references to SPDAT_RECORDS. eqemu_error.cpp has two references to CatchSignal, timeoutmgr.cpp has two references to timeout_manager, and spdat.cpp has a metric buttload of references to 'spells'.

The definitions may similarly be found: CatchSignal is defined in zone/net.cpp, as is SPDAT_RECORDS. I assume the other symbols are also present someplace.

[CoryWalker]

I also assumed that the definitions would be found easily but my assumption was wrong.

The externs are obviously referenced internally in libcommon.a and must be defined by the application that uses libcommon.a - and that's what makes this less straightforward.

The project I'm working on is to resolve a series of segmentation faults that I was getting when attempting to execute these applications on FreeBSD using the project's original build system. I created a very small test application - all it does is link against libcommon.a and then exist - to see if any application linked with libcommon.a could run without instantly crashing.

I first saw these 4 linker errors when I created my test application. I assumed that the other applications such as shared_memory, world, and zone would define these variables. However, the shared_memory code base defines none of these variables.

How does shared_memory ever get linked if the application files never define these externs?