While Anomaly's linux port "technically" works, it seems to have much lower quality standards than other Linux games on gog.com. Frankly, it looks like it was quickly thrown together by developers, from some beta-build. first of all, we have three separate game executables inside:

AnomalywarzoneEarth - 2605320
AnomalyWarzoneEarth - 2605320 (yes, difference is only in lower/upper case usage)
AnomalyWarzoneEarth-old - 2605352 bytes)

They're all NOT essential parts of game loaded in chain or something - you just use one of them, and two others sit idly unused, ever. 'AnomalywarzoneEarth' and 'AnomalyWarzoneEarth' seems to be copies of exactly the same file (same number of bytes), while 'AnomalyWarzoneEarth-old' is something different. I have no idea which one is recommended to use, and there is no explanation (in readme, or anywhere) what the difference is. Generally, it looks as there is no real one, but both executables seems to behave slightly differently as of if they start fullscreen or not during first startup.

Now, the real deal - Anomaly in Linux fails to terminate properly. In 99% of attempts to quit it via main menu result in freeze, and you have to kill it from separate terminal. As for 'AnomalyWarzoneEarth' executable, if you run it from terminal windowed, exit from in-game menu, and try to ctrl+c from it's terminal window, it WON'T work. 'AnomalyWarzoneEarth-old' is killable by ctrl+c from own terminal.
---

Overall, it looks very unprofessional. Sure, it's nice to have Linux port at all, but performance isn't too great, either - and I have strong feeling, that using windoze version through wine will result in better framerates, too (haven't had time to check it yet, - will do and report back). It feels too much like Witcher's linux "port"...

/Estel

11 Bit has been known to not give a rat's ass about GNU/Linux users. Right now, the game is broken. After the intro video, the game gets stuck loading, with the swirling logo. GNU C library update from 2.20 to 2.21 caused a conflict with the game as it is right now and, despite repeated reports from users in all forms, developers neither disturbed themselves into applying 5-minutes fixes found by the users, nor they gave any sign of life.

I'll explain: the problem is the same in all 11 Bit games, and the most precious feedback came from This War of Mine. The wonderful user nagical found out the problem in the Steam Forums

QUOTE: de.nagical[linux]
Bug in the game. Broken usage of sem_timedwait and/or absolute time waiting. Basically they call clock_gettime() and add 10000000 to the nanosecs, but they don't check for the nanosecs getting bigger than 1000000000 (1s), which glibc checks for. The returned error condition (-1/EINVAL) isn't handled by the game and instead it tries to wait even longer (until 0 is returned). Thus it just hangs.

Breakpoint 2, sem_timedwait (sem=0xed079c4c, abstime=0xed079b40) at sem_timedwait.c:26
26 in sem_timedwait.c
(gdb) p *abstime
$18 = {
tv_sec = 1436776731,
tv_nsec = 1001326413
}

Additionally, it seems that if the absolute time is already passed, the returned ETIMEDOUT would be also ignored.
Additionally 2, usleep() gets called with argument 0 most of the time oO
END OF QUOTE

The problem seem to lie in glibc's semaphore. However, no other games suffer from this. According to some users, recompiling the game would be enough, if I got that right (I know nothing about those things). The absurd thing is, while the devs ignore the whole GNU/Linux share of the people they received money from, all their support could come out with is "downgrade glibc to the latest version our games are known to work with". Which is an awesome way to break the system.

The worse thing is, the game officially only supports Ubuntu, which ships out new versions of the OS to update. That means that the problem first came out in Arch Linux, for the simple fact it is a rolling distribution and got the new version of glibc first. When an Arch Linux reported the problem, the devs responded "We only support Ubuntu". When a new version of Ubuntu came out, obviously shipped with the latest version of glibc, and hence Ubuntu users got the same problem too, they said "We are aware of the issue and we're working on it". Nobody has ever heard from them ever since, which means April 2015.

So, the solutions are substantially two. One is to download version 2.20-6 of glibc and unpack it in the game's lib directory. The problem is, even if the game is supposed to be 32-bits only, if I use 32-bits libraries it crashes with

support/gog_com.shlib: line 94: 1357 Segmentation fault (core dumped) ./"${bin_64}"

As if the executable really is 64-bits and I chose the wrong architecture for my libraries. So I downloaded the 64-bits libraries, but it seems to be hit-or-miss. Upon 6 tries, 2 times it worked, while the other 4 nothing changed.

The second fix, developed by nagical himself, is compiling a shared object to preload to work around the timing issue.

This fix seems to work for me, but the situation is not clear. The source code is compiled for 32-bits architecture, but when preloaded gives the following message:

ERROR: ld.so: object from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

That seems again to tell the binary really is 64-bits, and we chose the wrong architecture when compiling the workaround. However, compiling it for 64-bits gets the same error message, with wrong ELF class: ELFCLASS64. So, neither architecture works? Yes and no: despite giving that error, which tells us the .so was ignored, hence not loaded, hence it should make no difference, the game seems to load 100% of the times so far.

The problem is the devs did not disturb themselves by shipping the game with 2.20-6 glibc embedded, nor including nagical's .so workaround. Nor, obviously, taking the time to really fix the issue. You know, GNU/Linux users are more experienced, they can tend themselves and do the work for us. We can say we support the system, get our game bought by them and get their money, and all this without troubling ourselves with actually supporting the platform.
Money without work. Advantages without effort. Pros without cons. Who wouldn't want hat? 11 Bit found the golden goose. A platform for free. They don't have to do any work. Some capable user, like nagical, will come out and do the work for them.

tl;dr All this to say what? That the port is not half-baked, is half-assed.

But, I wanted to give my impression over the three executables.

Starting by saying to run the game I have to disable dri3 and preload the fix .so

env LD_PRELOAD=/home/dude/fix32.so LIBGL_DRI3_DISABLE=1 primusrun ./start.sh

I tried this running the three different binaries directly. I can say that all three work, there's no difference between AnomalyWarzoneEarth and AnomalywarzoneEarth (they even have the same md5/sha1 - and I have to report they start windowed and correctly fullscreen if focus is lost and given again to the game), while AnomalyWarzoneEarth-old directly runs in full screen, makes the system lose any focus (I can't change volume with multimedia hotkeys and I can't ALT+TAB or Super+D to minimize the game, I can only CTRL+ALT+F# to change session, if the game freezes. in order to be able to kill it). This, and it segfaults upon closing from the game's menu.

Does this error also effect the other games in the Anomaly series?:
- Anomaly Warzone Earth Mobile Campaign
- Anomaly Korea
- Anomaly 2
- Anomaly Defenders

or is it only a problem effecting the original Anomaly Warzone Earth?

As the problem in Anomaly Warzone Earth still is not fixed almost 3 years later I also would like to know that.

Cant get Anomaly 2 to work. I tried stuff and things, but no.

Coud not get Anomaly 2 and Warzone Eart running. Very disappointing...