Boost 1.54 has hidden dependency on GCC 4.x

[gabriel-francischini]

I just tried compiling inside a Docker virtual machine (ubuntu:cosmic-20190131) using GCC 8 (aka gcc-8 and g++-8) and it failed with an error very similar to this one . Compiling with gcc-4.8 is fine, though.

Turns out that the default ubuntu package libboost1.54-all-dev is built with GCC 4.x and there is an ABI break between GCC 4 and GCC 5+ which makes impossible to use this (and probably other libs built with GCC 4.x) with any modern version of GCC. Building Boost from source with a modern compiler may also fix this, but is probably overkill.

Since TravisCI is running an old ubuntu distro (trusty) and we are using the distro's default compiler while building (gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4, under Build system information) then we aren't having a broken TravisCI build right now, but this is something to keep in mind for the future when upgrading the codebase to modern compilers.

Also, apparently turns out that upgrading to modern compilers using TravisCI may be a headache too, albeit doable. It may be handy to have a Dockerfile.

This is related to #59 .

[y2s82]

Thank you for identifying the issue with detailed information.
I am quite interested in replacing as much boost-dependent code as possible with the standard library, and your issue makes me even more convinced that should be our first step forward.

In the beginning, we did in fact forced TravisCI to use the latest gcc/g++, latest boost, and latest everything, and ran into many issues. We reverted it all back to the build environment stipulated in the original code repository to make the project to build. We are currently trying to bring the codebase to the current standard, primarily Boost, and then libtcod (engine). I am hoping these changes will allow us to resolve many issues, including this compiler dependency issue.

As for Docker, I believe @rdittrich97 was using it to test out the builds on his workstation. Last I checked, that was setup identically to TravisCI to bring the project to build in the beginning of this fork. In the future, as the dependencies become more up-to-date, we can also bring the docker image to more modern representation to test the code.

[gabriel-francischini]

One of the nice things about Docker is that it provides isolation, so no matter where you are in the world or whatever is the configuration of your host computer, Docker is (almost?) guaranteed to run and return the same results.

On top of that, it is possible to hookup TravisCI in such a way that, in addition to running the usual builds, it also fires up Docker and builds goblin_camp using the docker image. With this configuration in place, we could always be sure that the docker image is buildable and produces the correct binary (i.e. the binary passes all unit tests).

This may sound way too similar with what TravisCI already provides (building the code and guaranteeing that it passes unit tests), but there's a key difference: it's a hassle and a time-consuming (and error prone!) process to either (1) set up a full-blown TravisCI server inside a development machine or (2) revert my ubuntu computer to trusty version and follow every step of the TravisCI configuration file. On the other hand, firing up a docker image and waiting it to automatically build the project is quite easy, even if you don't have Docker installed.

If we provide the right flags for static linking to the compiler, Docker may be able to produce a binary that doesn't depend on our dependencies (libboost1.54-all-dev, libtcod-1.9.0, etc.). This means that one developer can fire up docker, let it build the project inside its isolated environment, and run the goblin_camp binary directly in her/his host machine. Not only can this be a useful way to provide redistributable (release) binaries of the game, but also means that someone that 'just wants to build the game from source' can do so without ever needing to worry about which libraries we depend on - and thanks to TravisCI we can be sure that Docker will build without problems. Static linking is something that should be considered carefully since some libraries should never be statically linked (namely the C standard library and maybe the C++ standard library too), and some are recommended not to be statically linked for upgradeability/security reasons (SDL libraries), but given the project situation (in relation to legacy libraries) this may supply far more benefits than costs.

Not to mention that a developer can troubleshoot their building process using docker - thanks to it being isolated from the host configuration, the developer can be sure that issues in the build process are caused by the code instead of being caused by a misconfiguration in their host machine.

Recently, Docker started support for Windows-based images, so most of these key points may also apply to Windows builds. I do not know the current status of support for macOS images. Not to mention that is possible to install Docker in both Linux, macOS and Windows machines and be assured that it will run the Linux/Windows images in isolation even if your host isn't running the same OS of the image.

So, while Docker can give us a better path to use modern compilers, I think there are greater benefits to reap from it. I do not think it should be our primary build method, but it could be a handy guaranteed method to build the project.

I do agree about removing boost and upgrading libtcod. However, given the legacy status of the codebase, I'm afraid that doing so could (silently?) break something. It would be nicer to have unit tests first (which could be achieved using Catch2), so we could be sure that critical code areas haven't been broken in the process. Also, testing the unit tests in the biggest number of platforms/compilers possible would be better, since then we could be sure that at least in those platforms/compilers we didn't break anything. But in order to ensure the build process in multiple platforms/compilers, it would be better to already have a cross-platform battle-tested build framework (which is CMake). All this path have already been outlined/mentioned in multiple projects, issues and pull requests in this repository, so recently I started working in tidying up the CMake build file and upgrading it to a more modern version (currently we are using the default version, which is 2.x, and I plan to upgrade it to a 3.x version - possibly 3.2 or 3.6, or even the most recent if possible).

Turns out that Docker can be so useful that while preparing a pull request upgrading CMake I also ended up implementing a docker image that currently builds the project without problems. Without much trouble is possible to hook it up to the TravisCI and write some documentation explaining how to build the project using Docker, submit that as another pull request so that in the future (when we remove boost) we could use the Docker image as a base for upgrading/modernizing the compilers inside TravisCI.

[y2s82]

A custom Docker image does seem quite promising. It was something we had come across and wanted to implement but was just lower in our list of frustration. I would highly appreciate if you could take the charge on making this possible.

Please feel free to make incremental issues to achieve the process and make relevant PR's for each issue so we can start reviewing the code and configuration files.