Compiling the Source SDK on Linux
Since its release in 2004 Valve’s Source engine has been a popular platform for professional and indie game developers alike. A combination of great publicity through good games (Half-Life 2, Team Fortress 2, Left 4 Dead), functionality and solid mod support (I blogged about Steamworks earlier) has made it continue the legacy of the GoldSource engine.
I’ve learned the nuts & bolts the hard way, and I thought a quick rundown on how to compile the Source SDK on a linux-based system would be useful. Technical mumbo-jumbo behind the cut.
You’ve developed an existing client/server implementation (from scratch or based on the SDK sample code) on a Win32 platform, and would like to build and deploy some linux servers for your mod. Some hosting companies only support Linux server builds, or offer more interesting payment plans for Linux-based server rental.
I suppose you’ve got a working Visual Studio 2005 project for your mod. I haven’t tested it for VS2008/Express editions, but it should work okay.
- Recent 32-bit Linux distribution (Ubuntu, Debian, Slackware, …)
- Gnu C Compiler (GCC)
- Recommended version: 3.4.6 or anything higher in the 3.4.x branch. The documentation states 3.4.4 as the reference version, but I’ve found it runs into trouble with the supplied makefile.
- GCC 4.x or higher is not supported, but linked okay in my case. For more information check this repository.
- GLibC 2.3.2 (usually comes with the compiler)
- Xerces XML Parser 2.6 or higher : Is used to parse the VS project file. I tested with version 2.8.x, worked fine.
Converting the Visual Studio Project File
The process of compiling your Source mod for linux looks like this:
MAKEFILE -> VCPM -> MAKEFILE -> COMPILE MOD
The VCPM tool is compiled first, in order to compile the .vcproject files to a Linux makefile for your mod.
The Source SDK provides a makefile where you’ve got to fill in all the required details. It’s pretty straightforward, but you’ve got to pay attention to some details:
# the name of the mod binary (_i486.so is appended to the end)
Don’t use underscores or accents.
# the location of the vcproj that builds the mod
# the name of the mod configuration
Do not use ~ to refer to your home directory. Other options for the mod configuration are listed in your Visual Studio Project file. Typical : ReleaseWin32.
# the directory the base binaries (tier0_i486.so, etc) are located
Now here’s the tricky part: the Valve libraries for client-server communication (tier0_i486.so, …) are included in the Source Dedicated Server package, but not in the standard SDK. The only way to get the most recent versions of them is to install a dedicated server somewhere (check this thread), and then grab them from the server directory. Make sure to let the server fully update and run it at least once to verify.
This is a cumbersome operation, but there seems to be no other way. You’ll need the Half-Life dedicated server anyway to deploy your mod to. NOTE: this parameter actually has to be one directory up from where you placed the libraries, in contrary to what the descriptive text mentions.
Locations may vary.
# link flags for your mod, make sure to include any special libraries here
LDFLAGS="-lm -ldl $(GAME_DIR)/bin/tier0_i486.so $(GAME_DIR)/bin/vstdlib_i486.so mathlib_i486.a choreoobjects_i486.a tier1_i486.a"
Double check that these libraries are available. In my version of the Source SDK, the mathlib library was in a different directory, but this might have changed in the latest updates.
Locations may vary. Test Xerces first before you run the makefile.
Errors I’ve encountered
Things should run smooth as butter as soon as the makefile is configured correctly. We all know this will not happen. The VCPM tool should compile without too much hassle. If you can’t get it to build, double-check your GCC version and C library.
If things spin out of control after the VCPM process, there’s probably a problem with the converted makefile. Open it up in an editor and check the generated paths (which should point to your mod’s custom .cpp files).
If you get an error like this:
/usr/bin/g++-3.4 -w -I../dlls/../game_shared/hl2 -I../dlls/. -I../dlls/../public -I../dlls/../public/tier1 -I../dlls/../game_shared -I../dlls/../utils/common -I../dlls/../dlls -I../dlls/../../dlls -I../dlls/../dlls/hl2_dll -I../dlls/../dlls/hl2mp_dll
-I../dlls/../game_shared/hl2mp;./episodic -DHL2_EPISODIC -DHL2MP -DHL2_DLL -DUSES_SAVERESTORE -D_DEBUG -Dfopen=dont_use_fopen -DGAME_DLL -Dsprintf=use_Q_snprintf_instead_of_sprintf -DVECTOR
-Dstrncpy=use_Q_strncpy_instead -D_snprintf=use_Q_snprintf_instead -DPROTECTED_THINGS_ENABLE -mtune=i686 -march=pentium3 -mmmx -O3 ...
there’s an easy fix: remove any semicolons you’ve got in your VCProject. Works fine for defining project folders on WiN32, does not play along well in a makefile.
If compiling HL2 vanilla files is running fine (game_shared/*), you’re on your own. The errors you will encounter after that are probably project-specific. Get your #IFDEF LINUX out of the C++ toolbox, you’ll need it.
More information on the Valve Developer Wiki, which I’ve updated with my experiences. Another good resource is the HLCoders mailing list.
Was this article useful to you? Then don’t hesitate to Flattr me!