Bleh. Just for the hell of it, I’ve been trying to get an Altis Life server running (on Linux). This is a huge cramp, as documentation for this is rather lacking, and you get sent hither and thither to read documents that don’t make a lot of sense at first read, and for the most part, you have to translate the windows related docs to the linux environment. It’s not terribly difficult though.
The biggest hurdle has been getting extDB.so to compile. The arma3 server is 32bit, therefore the library needs to be 32bit. There’s documentation for it which sets up a whole chroot 32bit environment to compile it. Since I didn’t want to bugger up my server, I set up the chroot environment within a VM, although using the version of linux I’m running on the server, rather than the latest that the documents are geared for. I had some headaches, particularly with getting the correct version of libboost-dev installed, but once I got that right, I managed to get a compiled version of extDB.so. Copied the library to the server, launched arma, and it eventually told me (after connecting with a client) that extDB has not been loaded. I figured it’s probably because it’s dynamically linked and doesn’t have all the right libraries. I was right. So I manually copied all the required libraries over to the server, sticking them in /usr/local/lib (where there wasn’t much else to cause trouble), and tried launching the server again. So far so good. Connected with the client, got in and “Host has gone away”. Ugh. Core dump.
I figure the problem is that some of the libraries that extDB.so already detected on the server are actually 64bit, hence the core dump.
If I could get the shared library to compile statically (ie include the components it needs within it instead of dynamically linking at runtime), my problem would be solved - however I haven’t found a scenario where you can compile a shared library statically - and of course extDB uses cmake which I’m not familiar with at all. Apparently extDB was the devs first c++ project, which could explain the strange way (to me) that it is built.
If the library is compiled statically - that is with a .a extension, I’m not sure if the arma3 server binary will pick it up.
Alternatively - and this seems to be the method that is in mind in some of the documentation I’ve read - not only do you set up the chroot environment for compiling extDB, but you should run the server under it as well. This will apparently do away with the problems I’ve been experiencing, however it seems a bit counterproductive to run the server like this. It will also make it extremely problematic to update the script files etc. 
If the 32bit arma3 server can run on a 64bit system, why the hell can’t extDB.so?
This might help me later: c - Possible to build a shared library with static link used library? - Stack Overflow
Also might help: The Sorry Scheme of Things Entire: Linking static libraries into a shared library
Looks like the extDB dev is working on a static build. It appears that he was having problems building one of the dependencies statically, but seems to have figured it out. [s]He reckons he should have a static build soon![/]
I note that there is already a static build in the dev branch. I’ll grab it and test it later.
