I’ve been using Linux for almost thirteen years now. I’m a fan of this system and I can really say I’ve seen it’s evolution from mostly developmental state to polished system that can be used on daily basis for the power user. If you’re like me and you use your computer mostly for work, especially in areas of programming and network administration you know this operating system is a powerful tool generating more productivity if you know how to manage it well. This needs substantial amount of learning and learning curve for Linux is steep. But in the end you are able to do your work and daily routine tasks quicker.
Linux is not an ideal system and there’s certainly a room for improvement, especially in usability and user experience. Hardware incompatibilities are not such a big problem like they were few years ago. Software is abundant and you can find it for almost all, but the most specialized tasks. Like with every other operating system there are pros and cons of using Linux, but this is not the scope of this article. Perhaps I will write something about this in the future. Like most other *nix systems, Linux was built with networking in mind. This is the area, where I can honestly say that most of the time it outperforms other OS. Internet communication is smooth and despite some minor problems you can do whatever you want on the Internet and with computer networks.
There’s however one area where Linux is not so good. If you like playing computer games, Linux is definitely on the dark side when compared to Windows or even consoles. There are some commercial games ported to this OS of course and there is software like Cedega or Wine to emulate some games written for Windows, so they can run in Linux, but there are some problems with it. However if playing is not your primary focus for using computer and you’re just like me that from time to time you just want to relax and waste some time with rather simple games and games from the past, Linux offers you quite a good choice.
There are many open source games out there on the Internet. Various Linux distributions have them included out-of-the-box. There are many really funny and engaging games just for free, ready to be downloaded from the Internet and installed on your Linux system. Many sites like for example Happy Penguin offer a database of thousands of free games for Linux. If you’re using popular distribution like Ubuntu, Mandriva or Redhat, there’s good chance some of those games are already in the online repositories of those distributions. If not, there’s also a good chance you can download packages for your distro from the home page of the game.
Unfortunately, some games that are in development or their authors that don’t have time for creating packages for various distributions are only giving you game sources. And this can really give you a hard time if you are not a power user or at least you know how the compilation works and should be used. It’s true not only for games, but for software in general. The problem with software compilation on various platforms and architectures, under different Linux distros could be detrimental for your mental health if you are not expert user or even a programmer. This article is hopefully going to ease your pains, but it cannot bring relief to all headaches caused by compilation (games and software in general).
So. You’ve just come across an open source game you really, really want to play. You’ve checked online package repositories for your Linux distribution and found nothing or some really old version. Then you’ve checked the website of the game, but there are no packages matching your distro. There’s only this “source” thing for download. And it has this creepy .tar.gz or .tar.bz2 extension you really don’t know what to do with. But you give it a shot. So you download this .tar.gz/.tar.bz2 file and in the meantime you’ve learned it’s a compressed TAR archive file. What you should do now is to put your archive file in some directory like for example /home/user/games.
And now what? Well. Because it’s an archive you must unpack it. If you know how to do it just skip this paragraph. Unpacking is easy. There are some programs like Ark in the KDE that will offer you a graphical interface for unpacking this archive. Just remember to unpack it within subdirectory. If you prefer console (which most of the time is much faster for doing things like unpacking and compilation cannot be done without console usage) you can go to the directory where your archive file is (e.g. /home/user/games) and then issue command like this (if your archive ends with .tar.bz2):
tar xvjf archive_file.tar.bz2 .
or if your archive file ends with .tar.gz:
tar xvzf archive_file.tar.gz .
Remember that you shouldn’t omit space and the dot “.” at the end of this command. I won’t explain what it means, because you can google it or just read the manual. If you are really curious it means to extract archive file, creating directories, showing files extracted using specific decompression routines (GZip or BZip2). This should unpack the archive to the directory that’s usually the same as package name, e.g. superbgame-1.0.3.
When you have your source files extracted from archive you should enter the subdirectory with extracted files. This is where the compilation process occurs. So finally we can begin discussing what’s it all about.
First of all you should look for text files like README and INSTALL. You should read them, because most of the time they convey very important information regarding software compilation and installation process. They can specify prerequisites and requirements for compilation. You should read it carefully, because there are example commands and things you should check before you try to compile your newly downloaded software. If you stick to it usually compilation process will be smooth for you.
So let’s stop here for a moment. What is this compilation anyway? Compilation is simply a translation of programmer written code in so called programming language to native machine code. Of course it’s more complicated than this, but you shouldn’t bother. Native machine code allows your computer to read it’s instruction sets, effectively running a program when it’s executed. That’s all you need to know for now.
What are requirements for compilation? Mostly a compiler, build tools and so called development libraries. A compiler is a program which translates source code written in programming language to machine code. Depending on programming language the game is written in, there are various incompatible compilers. What it means? You cannot compile the game (or any software) with compiler written for another programming language. It’s like if you want the book translated from Chinese to English, using Spanish translator. You get my point. It won’t work. Compilers can also (and most of the time are) be incompatible even if they were written for exactly the same programming language. It can be explained as getting book translated from Cantonese to English, using Catalan translator. Of course most of the code will be translated correctly, but some words could be translated inappropriately. And unlike with book translation, if the whole source code isn’t translated correctly, it cannot be compiled and therefore used.
So let’s get back to our compilers. Most games for Linux are written in two programming languages, that are very similar (in fact sometimes they are treated as one) – C and C++. There are of course some games written in other languages like Java, Python and various others, but those are not in the scope of this article. We assume that most of the time games for Linux are written in C/C++.
Most widely used compiler on Linux based distributions is so called GCC. It’s an abbreviation for GNU C Compiler. This compiler is a set of tools that allow translation of various programming languages to machine code, but for clarity’s sake let’s assume it’s for C and C++ only (with exception that compiling C++ with GCC needs additional steps, but I will get to it later). Most of the time GCC is installed with your Linux distribution from the start. But you have to find out for yourself if it’s installed on your system, usually through software package management program. If it’s not you’ll have to install it and compiler’s dependencies (additional software). You can quickly check if it’s installed by issuing this command in console:
gcc -v
or
cc -v
And it should give you output like this at the end (among other information):
gcc version 4.4.1 (GCC)
If you get “command not found” error it probably means you have to install the compiler. This output is important. It tells you which version of compiler you have installed. Check out requirements stated in README or INSTALL files in the subdirectory where you unpacked sources of your game. If those files doesn’t state which version to use, most of the time it means you can use the latest version or even don’t bother about compiler version at all.
Remember. This will only give you information that you have GCC compiler installed. If the game needs C++ you’ll have to make additional check if it’s installed too. You can do this in a similar manner as with standard C compiler:
g++ -v
or
gpp -v
And it should give you similar or exactly the same output as standard C compiler. If you get “command not found”, you’ll have to check if it’s installed. Usually the package is named “gcc-c++” or “gcc-cpp”. If you’re sure you have this package installed and commands above are still giving you “command not found” errors it probably means, that your distribution is using “gcc” command for compilation of both C and C++. So you should be fine.
Ok. So we’ve discussed compiler. Of course there are other compilers like for example Dev-Cpp, but most games are written with GCC, so I’m not bothering to explain them. If you really want to compile something with other compiler you’ll have to ask for help elsewhere. Most of the time tips that I’m talking about could be applied to other compilers.
The second most important thing needed for compilation is so called build system or build tools. Those names are interchangeable (to some degree). What is a build system? Simply speaking it’s a set of various tools used for automating build process. Build process is a complete compilation process that encompasses all steps within compilation. Compilation consists of various steps like preprocessing, compiling and linking. There are various more or less popular build systems. The most commonly used in Linux is so called automake (which includes packages called m4, make, and various others). This is the most popular build tools set. From my experience 80% of all games and software projects uses automake for building final software package.
It consists of few steps, usually:
./configure
make
make install
Usually those steps are described extensively in README or INSTALL file. Issuing those commands in a build directory i.e. the directory source files reside, most of the time will work and give you compiled and installed program. Automake is by far most popular build system for games, from what I have seen.
There are of course other build systems like Scons for example. Scons needs Python to be installed on the system and it’s build process is somewhat different. It’s gaining popularity, so I’m mentioning it here. Building with Scons or any other build tools set will not be covered here. I recommend you to read installation instructions for your software. It should explain steps needed to compile a program with those tools. If not I recommend reading manual for those build tools.
Let’s focus on first command. The “configure” command. This command checks system for dependencies needed to build your software. It usually takes few parameters which are explained when you issue:
./configure –help
This will give you list of all available options. Some software can be configured to use extended capabilities or even make it optimized (software runs faster), but that depends on installed development libraries in the system. Let’s stop here for a moment.
What are those development libraries? Development libraries are “archives” (libraries) of routines used by your software. They can be used by many programs at the same time and are shared between programs. If program needs for example manipulation of JPEG pictures it would use routines from library that supports JPEG reading, manipulation and operations on JPEG pictures. Libraries are usually a set of functions that perform specific tasks.
Imagine for example a company. There’s a boss (that’s our program) and there are workers responsible for specific tasks (that’s our libraries). Worker can perform only a specific task (like for example financial accounting, carpentry or using a machine). That’s what libraries do. They do specific work for their boss or manager. Manager can be thought of as a library that uses other lower level libraries. When you run a company, for example building tables, the boss is responsible for running the company. He has various managers, who have responsibility for clients, finances, production and logistics. Those managers are libraries that our software (the boss) utilizes and which in turn are utilizing lower level libraries (workers) responsible for accounting, wood delivery, carpentry, warehouse operations and delivery to clients. Workers (low level libraries) depend on managers (medium level libraries) which in turn can be controlled directly by the boss (our software) or other managers (medium level libraries, so called middleware).
Software is a hierarchical structure just like the company. Almost all software uses some kind of libraries. Games especially depend on libraries that perform low-level graphic showing, audio management, input controlling and many other tasks. That’s why they need libraries someone else has written, because if someone would like to write a game only with his own code he’d probably do nothing else through his life, but write this one game. There’s no point. Programmers are specializing in some areas and expert in graphics will do graphics better than the person who has absolutely no knowledge about it. Libraries are sets of functions that can be utilized in various software without even knowing how exactly the specific task is performed. All that counts is expected output.
When compiling the code, various parts of the software are using so called “functions” from development libraries. That’s why almost all, besides the least complicated applications, depend on some libraries. Required libraries are mostly specified in README or INSTALL files I have mentioned. They can have various versions and hardware architectures they are built (compiled) for.
Most games in Linux depend on libraries like SDL (Simple DirectMedia Layer), Allegro, OpenGL (Open Graphics Library), OpenAL (Open Audio Library) and various other. There are many libraries responsible for graphics rendering, audio mixing and playback, input controlling, network routines, mathematical calculations, user interface drawing, system and hardware management and others. Usually those required libraries are specified.
Requirements are checked for availability when you run “configure” program from build system. It will tell you if something is missing by generating output like: “cannot find library libSDL_image” or something like this. This means you have to install the library so it will be available for build system. However. You may already have this library installed and configuration step of compilation is still not working. This means that you have only compiled library installed. Unfortunately software requires for compilation so called “header files”. Those header files are specifying what functions each library has. Compiler needs to know which library exposes specific function (routine). Header files are doing just that. They are exposing interfaces to the library functions, specifying exactly what should be given to function by the software (function input) and what should be expected in return (function output). Compiler knows that specific library exists in the system only by scanning available header files.
In most currently available Linux distributions those header files for a library are separate packages from the compiled library itself. Most of the packages within Linux distributions have additional package for each library ending with -devel or -dev suffix. When trying to compile your game (or any other piece of software) you have to make sure those development header files are installed alongside the library your software uses.
When those requirements are met you should be able to compile your game smoothly. However specific games can use either newer or older versions of library which are incompatible with application you want to get compiled. Sometimes when compilation fails because of unmatched major version of library, you can try to symlink the newer/older version. Most of the time it will work. For example you have /usr/lib/libSDL.so.1.3 and your game requires /usr/lib/libSDL.so.1.2. You can try to issue:
ln -s /usr/lib/libSDL.so.1.3 /usr/lib/libSDL.so.1.2
Sometimes it will work and sometimes it won’t but after all it’s worth a try. Sometimes you’ll have to compile older version of library by yourself. Remember you shouldn’t add –prefix=/usr option to configure command when you do this. Use another prefix like for example /usr/local/name_of_library_and_version. This will ensure stability for your system and it won’t allow to accidentally overwrite the version of the library you’re using system-wide (and probably many applications in your system depend on this version of library).
The –prefix option for configure command tells where the software should be installed. Most of the time into PREFIX/bin goes executable files, PREFIX/lib goes library files and to PREFIX/share goes data files required by the software (but sometimes data files can go into PREFIX/lib, depends on programmers fantasy). If you want to install your software system-wide you should always use configure –prefix=/usr.
That’s all for now. The next note will explain things further and I will explain more advanced concepts and also try to show you some tips and tricks regarding the compilation process of the software. I hope you enjoyed reading this article. Feedback is appreciated.
