We Know the Devil

We Know the Devil

View Stats:
DrMcCoy Feb 16, 2016 @ 2:26pm
GNU/Linux support?
Is there any chance for GNU/Linux support?

As I understand, the game itself is HTML-based, so you should only need to port the wrapper around whatever browser thing you're using (CEF?), right?
< >
Showing 1-11 of 11 comments
Date Nighto  [developer] Feb 23, 2016 @ 12:34pm 
I JUST realized that Dr. McCoy could be Bones or Hank, WHOA. Also, we tested a Linux build, but didn't have time to validate. Can you tell me what version of Linux you're using, and we'll take a look? We're testing Linux with a VM.
Conrad Feb 23, 2016 @ 12:49pm 
Lead dev here. Not CEF exactly but Electron, otherwise you have the right of it. I validated it in Ubuntu, but wasn't able to ensure that the libs required would be available in Mint or Fedora for example. Any info you could provide about your setup would help me determine what environments I should be testing in.
DrMcCoy Feb 23, 2016 @ 2:51pm 
Originally posted by DN konistehrad:
I validated it in Ubuntu, but wasn't able to ensure that the libs required would be available in Mint or Fedora for example.

AFAIK, in general, the idea for Steam on Linux is that you target Valve's SteamOS. That's currently based on Debian Jessie, while the previous versions were Debian Wheezy and before that Ubuntu-based. You might want to try it in previous Ubuntu versions too, like 15.04 or 14.04 LTS. Unless you're hitting an edge case, that should all be a wash.

Additionally, you have the libraries that Steam's runtime itself provides. That's probably not that relevant for your usecase, unfortunately, but Steam's runtime is coming with a whole set of game-y libraries like SDL, libasound, ...

Anything unusual/uncommon, you'd provide as .so files yourself, and then add a start script that sets the environment variable LD_LIBRARY_PATH to point to your libraries. Alternatively, you can alter the ELF binary of your program itself and set an rpath. You'd do that with patchelf[nixos.org].

If you're providing both 64-bit and 32-bit support, you'd query that in a start script as well, by calling "uname -m" and checking for "i686" (32-bit) or "x86_64" (64-bit). (Or a host of other values, if were supporting non-Intel/AMD-architectures.) Of course, an x86_64 GNU/Linux will still run i686 binaries, but not vice versa. So if you don't want to go through the trouble there, just go 32-bit only.

Looking at the Linux binary release package for Electron, it comes with libffmpeg.so, libgcrypt.so.11 and libnode.so. libgcrypt.so.11 is within the Steam runtime, so you won't need to provide that. The other two, however, you would. Otherwise, the binary and those libraries don't seem to depend on anything else uncommon, so from Electron's side, you'd be golden there if you just drop in libffmpeg.so and libnode.so.

The electron binary coming with that release package already has a rpath set up too (to "$ORIGIN:$ORIGIN/lib/", i.e. the directory of the binary and a "lib" subfolder there). So, again, just distributing those files should work painlessly everywhere, if you're using that binary and don't depend on anything else.

If you do depend on anything else (apart from the standard C runtime libraries and libstd++, of course) , basically check if it's in the Steam runtime. If so, you don't need to do anything. Otherwise, distribute it with your game.

Originally posted by DN konistehrad:
Any info you could provide about your setup would help me determine what environments I should be testing in.

I'm running Debian Sid (unstable), with some packages from experimental pulled in. Me personally, I can probably cope with basically everything you can throw at me. But my system is not necessarily the right one to check if something will work everywhere else, I'm afraid.

Sorry for that long rambly post; hopefully you can pull some useful information out of it. If you have any questions, I'd be happy to answer them.
Conrad Feb 25, 2016 @ 5:03pm 
Woah, first thanks for such a detailed post. As some background: I'm the person who spearheaded the Linux build of Guns of Icarus: Online, so fortunately those were all the feedback points I was hoping to hit, yeah. On this game's build, I split 32/64 into different packages, so only the correct one comes down the pike making the `.sh` launcher file much simpler for this case.

I was testing on Ubuntu LTS versions, all of which went down to 14.04 with flying colors; in your experience do these match up well with SteamOS? I remember supporting Linux on GoI was a pain, namely there were times when, I kid you not, libc would fail to `ldd` properly. In your experience, is this something I have to watch out for still or has this settled down?
Conrad Feb 25, 2016 @ 5:04pm 
(Good pull on rpath too; that gave me no small amount of trouble on GoI haha)
DrMcCoy Feb 25, 2016 @ 5:55pm 
Originally posted by DN konistehrad:
I'm the person who spearheaded the Linux build of Guns of Icarus: Online

Neat. :)

Not my kind of game, but I know some people who had a lot of fun with it.

Originally posted by DN konistehrad:
On this game's build, I split 32/64 into different packages

Oh, right, I forgot that this is a thing you can do with Steam.

Originally posted by DN konistehrad:
I was testing on Ubuntu LTS versions, all of which went down to 14.04 with flying colors; in your experience do these match up well with SteamOS?

Pretty well, yes.

Originally posted by DN konistehrad:
I remember supporting Linux on GoI was a pain, namely there were times when, I kid you not, libc would fail to `ldd` properly.

Generally, compatibility issues with libc happen if you try to use something build with a new libc on a system with an older libc. The other way round should work flawlessly [1]. So if you build your binaries on an old enough system, that should take care of everything. (I have a Debian Wheezy chroot set up exactly for this, for example.)

There's also a few things to look out for with libstdc++, the GNU STL library. C++11 breaks ABI compatibility in a few places (thanks to std::list::size() having to be O(1) now, mostly). With the GCC 5.1 release, libstdc++ gained a dual ABI, selectable on compilation time. See https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html for details [2]. In general, the old ABI is "more portable" than the new: newer systems will still run the old binaries, but older system will lack the necessary symbols/code. The libstdc++ coming with Steam also lacks the new ABI, because that's libstdc++ 6.0.18, which came with GCC 4.8.0.

So if you're using the STL and are compiling your own binaries, you should select the old ABI and/or compile with gcc < 5.1. If you want to be on the safe side, compile on a system with gcc <= 4.8.0 and a libstdc++ <= 6.0.18. Debian Wheezy, for example, comes with 4.7.0 / libstdc++ 6.0.17. That way, the Steam-provided libstdc++ will work, even if the system-provided one fails the test.

So, to recap, if you're building your own binaries, build them on an older system (but not too old). If you've run through old Ubuntu versions, and your stuff still works, it should in general be okay and work basically everywhere.

Originally posted by DN konistehrad:
In your experience, is this something I have to watch out for still or has this settled down?

It should really be settled now. If you do encounter any issues, then I'd be quite interested about them as well.


[1] With some exceptions. Compatibility was broken back in the days (around 2000) in one libc5 version, that made some older Loki releases break. Now, with libc6 being out for ages, that can be remedied by just only using the older libc5 that no one else needs at all anymore.

There was also an issue with Debian, when they used the eglibc instead of the glibc for a while, and some versions didn't play nice. That's also not relevant anymore, though, as it *should* have been fixed. That might have been the issue you encountered.

[2] That also introduced incompatibilities with clang, which provides its own STL, but could also use the GNU one (necessary if you're using C++ libraries that were compiled against the GNU STL, like Boost, for example). I *think* they were fixed, though.
Conrad Feb 25, 2016 @ 7:12pm 
Originally posted by DrMcCoy:
(I have a Debian Wheezy chroot set up exactly for this, for example.)

That's a pure-gold lead; I have to build the Node<->Steam API package manually for the specific Electron version, and this is definitely something I'll take into consideration. (I think I built on 15.04, but I can VM into 14.04 instead.)

I'll throw a few more VM's at it in the coming weeks to make sure everything sticks. If it all shakes out right hopefully I can have the Linux version out by mid-March. :) Oh, also, if you're interested in beta testing please throw me an email: conrad@datenighto.com and I'll set us up a facility for that.

Thanks again!!
notboxbot Jun 26, 2016 @ 4:18pm 
Any news on the Linux version? It has been a while...
DrMcCoy Jun 26, 2016 @ 5:24pm 
Oh, right, I completely forgot about this. I'm still very interested in playing this game on GNU/Linux! :)

(IIRC, I also didn't send a mail about wanting to help beta-testing, because I have a memory like a sieve sometimes, sorry. I hope that's not why there's no news...)
morningbird Oct 14, 2016 @ 4:52pm 
Can we get the Linux version? I would like to play this.
Cathulhu Feb 22 @ 11:05am 
Add me as another person very interested in a linux port.In the meantime: Does anyone have any guides for making the game run through WINE?
< >
Showing 1-11 of 11 comments
Per page: 15 30 50