Compiling under Linux

Creating a Linux build of your multiplayer dedicated server or server plugin is not required, but does make it much more likely to be accepted by commercial server operators.

Note:Building on Linux requires an existing Visual Studio project, which is converted to a makefile by Valve's vcpm tool ("Visual C++ Project to Make").

Getting Linux

There is a bewildering array of Linux distributions. If you are unsure which to use go for Ubuntu, which tries to be user-friendly. It has a "software centre" that makes installing packages simple.

64-bit

64-bit builds of Linux compile in 64 bits by default. While it is possible to compile in 32-bit in such an environment, and this page will detail how, your life will be easier if you use a 32-bit distribution.

Requirements

• GCC including G++ (4.2.2 recommended)
• Xerces XML parser 2.8.x
• GLIBC 2.3.2 or above

64-bit:

• ia32-libs (or you will be told that 32-bit binaries don't exist)
• Make sure you have the 32-bit build of Xerces.

Fixing the makefile maker

Bug:Don't use ~ for your home directory since parts of the make process will not understand it.  [todo tested in ?]

Open sdk_root/linux_sdk/Makefile

Most of the config options here are straightforward, except for:

GAME_DIR

To get this, you need to download a dedicated server from Valve. You'll also have to find/replace the names of the libraries the makefile searches for:

• tier0_i486 > libtier0
• vstdlib_i486 > libvstdlib
• steam_api_i486 > libsteam_api

CC, CPLUS, CLINK

If the compilers are not where the makefile things, it may work to change them to just gcc or g++, without a path. Otherwise correct the path.

If you are compiling under 64-bit, add -m32 to the end and wrap in quotes, e.g. "g++ -m32".

CPP_LIB

Again, these files may not be where Valve think they are. To find them, browse to /usr/ and search.

64-bit users will probably encounter two files; choose whichever has '32' somewhere in its path.

Open sdk_root/public/tier0/platform.h

On line 46 replace <new.h> with <new>.

Todo: Currently getting "shadows template parm" errors when building server...plugins work though.

Building

Once configured correctly, making your mod should be a simple as:

export LD_LIBRARY_PATH=.
make

Bugs

Confirm:These details are very old and may no longer be relevant.

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 {
global:
  CreateInterface;
local:
  *;
};

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.)

The newer version of the SDK also makes symlinks to prevent trouble with tier0_i486.so.

--- Makefile.vcpm       Sat Oct  1 22:26:26 2005
+++ Makefile.vcpm       Sat Oct  1 22:25:43 2005
@@ -14,12 +14,12 @@
 TIER1_OBJ_DIR=$(BUILD_OBJ_DIR)/vcpm/public

 #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)
+CFLAGS= -w -fpermissive -D_LINUX -DNDEBUG $(ARCH_CFLAGS)
 #DEBUG = -g -ggdb
 #CFLAGS+= $(DEBUG)

 INCLUDEDIRS=-I$(PUBLIC_SRC_DIR) -I$(XERCES_INC_DIR) -I$(UTIL_COMMON_SRC_DIR) -I$(TIER1_PUBLIC_SRC_DIR)
-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 @@
        $(DO_CC)

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

 clean:
        -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

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.)

See also

• A repository which supposedly contains GCC 4.* capable source code