Linking against libcommon.a fails

[CoryWalker]

I am able to create libcommon.a without any linker issues at all. However, when I attempt to further link against libcommon.a and create an executable - such as shared_memory - I get the following 4 linker errors:

--
g++49 -o test -nodefaultlibs -L/usr/local/lib/gcc49 main.o /usr/local/build/everquest/common/libcommon.a /usr/lib/libthr.so /usr/local/lib/mysql/libmysqlclient.so -lgcc_s -lstdc++ -lc

/usr/local/build/everquest/common/libcommon.a: undefined reference to `SPDAT_RECORDS'

/usr/local/build/everquest/common/libcommon.a: undefined reference to `CatchSignal(int)'

/usr/local/build/everquest/common/libcommon.a: undefined reference to `timeout_manager'

/usr/local/build/everquest/common/libcommon.a: undefined reference to `spells'
collect2: error: ld returned 1 exit status
--

I know the exact cause of the errors. However, I do not know what the safe way of fixing the issue is. All of these errors are caused by declaring external variables in a header file but are not defined in the application that uses them - at the very least shared_memory is not defining them.

The following extern variables and functions are in question:

spdat.h, line 754:
extern int32 SPDAT_RECORDS;

eqemu_error.cpp, line 32:
void CatchSignal(int sig_num);

timeoutmgr.h, line 64:
extern TimeoutManager timeout_manager;

spdat.h, line 753:
extern const SPDat_Spell_Struct* spells;

What is the best way to resolve this issue? Are these globals still used? Should I manually defined them? Should I just delete them and recompile/relink?

[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?

[jdoran]

As I said, the application DOES define those. The two I checked were in net.cpp

[CoryWalker]

I'm asking about the shared_memory application and you are responding about zone.

There is no net.cpp in the shared_memory application codebase and this application does not define these symbols.

[jdoran]

Sorry, I misread you.

The shared_memory executable does not reference any of those undefined symbols. I base this on "nm shared_memory". The symbols are not present, neither in a defined state nor an undefined state.

For example: SPDAT_RECORDS is only used in IsValidSpell, which is not used in shared_memory. I'm not going to look at the other symbols, since they will probably be similar cases. But a grep of the shared_memory source does not turn up a reference, nor is there one in the symbol present in the executable. If the symbol were used (even indirectly) I would expect a symbol table entry.

This code is linking and running under Linux, so there is no underlying problem with undefined symbols. I'm not sure what FreeBSD is doing, but there might be some oddball linkage editor setting.

[CoryWalker]

Thanks, jdoran. I've analyzed the default libcomon.a creation commands. The cmake commands that FreeBSD uses to create libcommon.a are these:

--
ar cr ../bin/libcommon.a (object files list ...)

ranlib ../bin/libcommon.a
--

These are their respective versions:

ar -V
GNU ar (GNU Binutils) 2.24

ranlib -V
GNU ranlib (GNU Binutils) 2.24

A note about the above commands. This is what the existing cmake build system does - provided by the project.

Can someone get the commands that Linux uses to create libcommon.a and get me the versions of these utilities?