Lots of zlog, mlog references but not included in source
 

It appears that some of the logging libraries are not included in the main source repository. Specifically, zlog and mlog appear to be used frequently but prevents world and zone - respectively - to compile.

I found a couple of good candidates that might be what is being used:

HardySimpson/zlog
zschoche/mlog

Is this right?

Thanks for pointing me in the right direction.

Do I just need to add a -DDISABLE_LOGSYS compiler switch to satisfy these references?

Dude, just use cmake and make.

"cmake / make" doesn't work on FreeBSD systems readily.

The existing cmake build system included with eqemu doesn't know how to link zone propertly. All other programs such as shared_memory and world instantly crash because they are not linked correctly.

I'm trying to determine the cause of these issues and therefore must reconstruct the compilation steps.

What are the cmake commands you're running?

Back when I got it to compile on FreeBSD (didn't actually do any runtime testing) I had to override CC and CXX like

the '..' because I was building in a subfolder.

I run "cmake ." I then change the CMakeCache.txt file to target the CC, CXX compilers I want to use. Then I run make.

Everything works up until the zone link attempt is made. Both shared_memory and world are linked by this point - but running either one of them causes segmentation faults - so there is something not compatible happening with FreeBSD.

you need to set it in the env variables before you run cmake, like I posted. Just changing those probably isn't doing everything right.

You can - but do not need to - set the CC and CXX environment variables in order to get the compiler settings you want with cmake. Cmake creates a CMakeCache.txt file and then you can tailor it to your needs by editing the cache file. This is exactly how the cmake build system works.

I have verified that the compiler commands that I want to use actually are being used by using gmake's VERBOSE=1 switch - so a misconfiguration of cmake is most certainly not the problem here.