CDDA Linux Builds for amd64 (64bit) systems

Game Talk The Garage
1

I’ve been using the Linux Console experimental builds on my system for quite a while now without having experienced any problems. But now that I’ve switched to a 64bit build of my distro (because of upgrading to 8GB RAM and also due to the fact that 32bit has gradually become obsolete), I’m not sure on how to run these builds anymore.

The classic way to run 32bit applications on Linux (i.e. installing adding i386 arch and installing i386 versions of core libraries like libc, libstdc++ and libncurses) also doesn’t work. I added the i386 architecture as instructed:

$ sudo dpkg --add-architecture i386
$ sudo apt update

I then installed the i386 versions of the core libraries:

$ sudo apt install libc6:i386 libncurses5:i386 libstdc++6:i386

I then downloaded the latest C:DDA linux-console experimental build (as of now) and extracted it:

$ wget http://dev.narc.ro/cataclysm/jenkins-latest/Linux/Curses/cataclysmdda-0.C-6376.tar.gz
...
$ tar xzf cataclysmdda-0.C-6376.tar.gz
$ cd cataclysmdda-0.C

But when I tried to run the C:DDA binary (with the requisite permissions), it printed an error and exited:

$ chmod u+x cataclysm
$ ./cataclysm
./cataclysm: error while loading shared libraries: liblua5.2.so.0: cannot open shared object file: No such file or directory

I’m on an up-to-date Debian Testing amd64 machine.

Compiling C:DDA is a pain; not because of missing libraries and stuff but because cloning the git repo takes forever. The first time I tried cloning the git-repo, it began fetching stuff which went over ~50M and then I quit that… because I’m downloading the source-code of a roguelike not some bloated electron-app. Even If I download the source (which will take a long time on my ~100KBps connection), it is not feasible since I’ll have to download it over and over again due to the lack of a current stable version.

So how should I go about running the 32bit binary of the latest-experimental? And more importantly why a 64bit build of C:DDA isn’t available? After all, most of the users would be using 64bit system with 4GB+ RAM becoming a necessity in today’s world. I know it isn’t fair to assume that everybody uses an amd64 distro but there should be an option because the 32bit binary doesn’t work right now.

On a side note, why is a roguelike like C:DDA has such a huge master repo? And if the repo is indeed huge and it can’t be helped then shouldn’t an updated version of the source code stripped-off of needless stuff be available on the site?

2

You need the 32-bit version of liblua5.2, I don’t remember what Debian calls it.
I’m planning on eliminating this dependency, partially for this specific reason.
On non-linux unices you may need a 32-bit gettext as well, Linux distros tend to bundle gettext with libc, but BSDs don’t.
If you want to run with tiles* you’ll also need 32-bit SDL, sdl_ttf, sdl_img, and SDL sound.

The repo for dda is huge because it’s a huge program with a very long development history. In file size it’s dominated by tilesets like any game with graphical elements, but the ~250,000 lines of c++ and 500,000+ lines of json defining game entities adds up. The reason the clone takes so long is we’re currently sitting at commit number 49,769, and a clone can reproduce any one of those commits.

If you want to build the source but not develop, there are several options better than a git clone.
On the GitHub page there’s a link to download a tarball or zip of the source code.
You can do a git “shallow clone” that only retrieves the latest version of the code without retrieving all of the history.
If you keep your clone around and do “git pull” before a build it’s much less to download than a full clone.
I haven’t done it, but I’ve heard there’s a way to avoid checking out certain files or directories, so you might be able to clone without pulling the tilesets, which would greatly reduce data volume.

*Sounds like you don’t want tiles, but I’m answering for someone else who might read this thread.

3

[quote=“Kevin Granade, post:2, topic:13568”]You need the 32-bit version of liblua5.2, I don’t remember what Debian calls it.
I’m planning on eliminating this dependency, partially for this specific reason.
On non-linux unices you may need a 32-bit gettext as well, Linux distros tend to bundle gettext with libc, but BSDs don’t.
If you want to run with tiles* you’ll also need 32-bit SDL, sdl_ttf, sdl_img, and SDL sound.[/quote]

Thanks for clarifying. I was expecting something similar because the error was that the shared library couldn’t be found but I haven’t worked much with native x86 binaries in an amd64-system so I was not sure what to do at that point. The lua libraries which are in the Debian-repositories are liblua5.1, liblua5.2 and liblua5.3 and my system had all of them installed. So what I needed to do was to just install the i386 version of liblua5.2 and the game-binary ran perfectly after that.

$ sudo apt install liblua5.2-0:i386
...
$ ./cataclysm

I also needed to install the libncursesw library because it is needed along with libncurses5 (which I had installed previously).

$ sudo apt install libncursesw5:i386

Furthermore I was able to find the 64bit binaries for the game (albeit only for Curses which is fine by me) buried in the downloads server at the latest experimental link on the website. The binaries can be found here: Index of /cataclysm/jenkins-latest/Linux_x64/Curses, while the website only gives link to the 32bit binaries (erroneously labeled Linux rather than Linux_x86) here: Index of /cataclysm/jenkins-latest/Linux/Curses .

If anybody reading this thread wants to run the latest experimental builds on a 64bit system they can either:

[ul][li]Download the 64bit binary from the server which is only for the console. Or,[/li]
[li]Install the i386 versions of all the requisite libraries (obvious ones like libc6, libncurses5 and libstdc++6 and not so obvious ones like liblua5.2 and libnucursesw5) You also need to install the i386 versions of the required SDL libraries if running the tiles version.[/li][/ul]

tl;dr The game works correctly after installing the i386 versions of liblua and libncursesw.

The repo for dda is huge because it's a huge program with a very long development history. In file size it's dominated by tilesets like any game with graphical elements, but the ~250,000 lines of c++ and 500,000+ lines of json defining game entities adds up. The reason the clone takes so long is we're currently sitting at commit number 49,769, and a clone can reproduce any one of those commits.

If you want to build the source but not develop, there are several options better than a git clone.
On the GitHub page there’s a link to download a tarball or zip of the source code.
You can do a git “shallow clone” that only retrieves the latest version of the code without retrieving all of the history.
If you keep your clone around and do “git pull” before a build it’s much less to download than a full clone.
I haven’t done it, but I’ve heard there’s a way to avoid checking out certain files or directories, so you might be able to clone without pulling the tilesets, which would greatly reduce data volume.

I get that the source code repo is huge because after all it is a huge game with a long development history. I’ve also been looking for an easy way to just clone the things I need (like all the source-files needed for a Curses-build) but I guess that’s easier said than done. I’m not a dev so obviously I don’t know much of git but I would certainly like to know what ways are there to clone just once and pull only the files that were updated later on, like you said.

Can you provide the exact incantations for that? because honestly, the git manpage is lengthy and quite confusing for a complete beginner like me.

4

You’re most of the way there if you have a completed clone, just enter the directory and do “git pull”. It’s trivial if you have no local changes to tracked files.

5

I never had to install the i386 versions of any libraries to get the tiles version of 64 to compile on Ubuntu.

6

That’s because you were compiling, this is about getting the 32 bit build to run on a 64 bit system.