Difference between revisions of "Compiling under Linux"

From Valve Developer Community
Jump to: navigation, search
(Added section on GLIBC versions.)
(Setting up the Makefile: remove overly speculative commentary)
Line 28: Line 28:
<code>CreateInterface</code> is the only dynamic symbol you need to export. This looks like an oversight on Valve's part - removing the rest will save around 5 megs of pointless and possibly dangerous exports. (It is much easier for other people to disassemble your code when you export all of your functions.) Here's a version_script to fix it:
<code>CreateInterface</code> is the only dynamic symbol you need to export. This looks like an oversight on Valve's part - removing the rest will save around 5 megs of pointless and possibly dangerous exports. Here's a version_script to fix it:

Revision as of 16:17, 5 May 2007

Adding a Linux version of your multiplayer mod server allows more sites to be able to host servers. More hosting increases the chance of your mod being a success. Much of the grunt work of getting a Linux server binary created has been automated. This document describes the environment and configuration needed to get you going with a Linux port.

How to obtain

The SDK is distributed via the Windows version of Steam. Get the SDK by looking under the View menu, choosing Tools, and double-clicking Source SDK. Run it when the installation is done, choose Create a mod and Source code only, create a new directory for it (e.g. hl2sdk) and let the SDK program do the rest.


The following tools are required to compile the SDK under Linux. Any other version will probably cause complete failure at compile or run time. (Nothing prevents you from experimenting with the latest and greatest versions while your mod is in development, but server admins won't like you if your server library causes crashes!)

  • GCC 3.4.1 or above on the 3.x branch. (3.4.4 recommended to fix an offsetof bug.) GCC 4.0 and 4.1 compile and link too, but don't count on your mod running perfectly; there aren't any detailed success/failure reports from such configurations.
  • Xerces XML parser 2.6.0 or above.
  • GLIBC 2.3.2 or above.

Slackware 11.0 ( http://www.slackware.com/ ) is a good starting base to create your compiling environment.

Setting up the Makefile

As part of the compile process, the Microsoft Visual C++ Project file used to compile your mod under Windows is converted into a snippet of a Makefile. This conversion process needs to be seeded with a few configuration parameters, all of which are contained in linux_sdk/Makefile. At a minimum you should configure these parameters:

  • MOD_PROJ, the filename of the Windows project file used to compile your mod.
  • MOD_CONFIG, the configuration set to use when compiling the Linux version of your mod. Typically this is the Release Win32 option. The easiest method to determine this parameter is to leave it at default, run the make process once and then look at the Makefile snippets that are produced, choosing the appropriate one.
  • GAME_DIR, the path to an installation of the game. The Makefile says "the directory the base binaries (tier0_i486.so, etc) are located" but actually it wants one level up from the directory with tier0_i486.so.
  • CC, CPLUS, CLINK, CPP_LIB, these parameters should be pointed to your particular install of GCC that you wish to use for compiling your mod/plugin.
  • XERCES_INC_DIR, XERCES_LIB_DIR, the installation directory of the Xerces library.
Note:Don't use "~" for your home directory since parts of the make process will not understand it.

Once these configuration parameters are set compiling your mod should be a simple as running:


CreateInterface is the only dynamic symbol you need to export. This looks like an oversight on Valve's part - removing the rest will save around 5 megs of pointless and possibly dangerous exports. Here's a version_script to fix it:

$ cat mod/src/linux_sdk/version_script
VERS_1.1 {

Several people have reported a bug that "export LD_LIBRARY_PATH=~/source/bin" was required before vcpm would run. Here's a patch to fix that bug. (If you haven't applied the SDK Known Issues List#First_big_pass_at_-Wall_and_consistent_code fixes, you will have to take out the -D changes below.)

--- Makefile.vcpm       Sat Oct  1 22:26:26 2005
+++ Makefile.vcpm       Sat Oct  1 22:25:43 2005
@@ -14,12 +14,12 @@

 #we use custome CFLAGS because the base ones interfere with XERCES
-CFLAGS= -w -fpermissive -D_LINUX -DNDEBUG -D_alloca=alloca -D_snprintf=snprintf -D_vsnprintf=vsnprintf $(ARCH_CFLAGS)
 #DEBUG = -g -ggdb

-LDFLAGS_VC=-lm -ldl -L$(XERCES_LIB_DIR) -lxerces-c $(GAME_DIR)/bin/tier0_i486.so $(GAME_DIR)/bin/vstdlib_i486.so
+LDFLAGS_VC=-lm -ldl -Wl,-rpath -Wl,$(GAME_DIR)/bin -L$(XERCES_LIB_DIR) -lxerces-c $(GAME_DIR)/bin/tier0_i486.so $(GAME_DIR)/bin/vstdlib_i486.so

 DO_CC=$(CPLUS) $(INCLUDEDIRS) -w $(CFLAGS) -DARCH=$(ARCH) -o $@ -c $<

@@ -51,7 +51,7 @@

 $(TIER1_OBJ_DIR)/%.o: $(TIER1_SRC_DIR)/%.cpp
-       $(DO_CC) -Dstricmp=strcasecmp -Dstrcmpi=strcasecmp
+       $(DO_CC)

        -rm -rf $(VCPM_OBJ_DIR)

This will compile the vcpm program, run this against your VCProject file and then use the resulting Makefile snippet and the configuration parameters you set above to compile your mod.

Since you're using GCC, you may also want to look into SDK Known Issues List#Getting the SDK to work under -Wall -Werror.

Running your Mod

To run the mod copy the file produced by the make process to mod dir/bin/server_i486.so and then run srcds_run with the appropriate -game parameter.

Miscellaneous information

How can I know if my GCC version will work?

First, try compiling the SDK whole. If it doesn't work, then you'll have to choose a different version.

If it worked, a factor might cause silent failures later on: the version of the Standard C++ Library. You can consult the list of GCC and libstdc++ versions in the libstdc++ documentation. The major version number (first of the three) of the library is increased each time a change that breaks backward compatibility is performed. The current builds of the Source Dedicated Server require version 6; any other version, older or newer, will not work.

GLIBC version caveats

The C library, just like the C++ library, is a bit demanding. You can't expect server administrators to upgrade straight away to bleeding-edge (on the contrary, they take their time, mainly with such important components such as libc), so it's your job to make the library work on as many systems as possible.

Each new GCC version tends to require newer GLIBC versions. GLIBC is designed in a way that if you don't use any backwards-incompatible functions, your library will function on systems with older GLIBC versions than the one you've used while compiling.

To look at the requirements of your current file, look at the last section of the output of this command:

readelf -V library.so

Currently, the best compatibility/functionality tradeoff would be achieved with version 2.3, which is available on Ubuntu since "warty", on Debian since at least "sarge", on Fedora Core since Core 1 and OpenSUSE since 10.0. (Newer distribution releases will contain newer GLIBC versions, but, fortunately, there is forward compatibility.)

If, therefore, the readelf output contains a higher number than GLIBC_2.3, you might be using some features maybe too advanced for some systems. (With GCC 4.1, you'll have to add -fno-stack-protector to your USER_CFLAGS to turn off such a feature (the stack-thrash protector). If you want to know which potentially bad functions are being referenced, run the following:

nm library.so | grep GLIBC_2.4

(Replace 2.4 if it's a different version causing complications.)