Talk:Compiling under Linux

From Valve Developer Community
Jump to: navigation, search

Maybe a more indepth tutorial including how to install Xerces XML parser 2.6.0 or above ( http://xml.apache.org/xerces-c/ ). Because I am stumped when I try to install that.

Maybe this can help? I'm currently trying it out: http://debian.mirror.inra.fr/debian/pool/main/x/xerces-c2/ It required libicu38 to install on my server. It seemed as if apt-get install libicu38 may already have installed xerces as well. Won't test that anymore... obviously. Bahlanth

Perhaps more indepth for everything:o but then again this isn't for people new to linux, its for those who know what they are doing with xerces and gnu make --Draco 03:08, 23 Jul 2005 (PDT)

But lots of people have knowledge of windows but very little of linux some more indepth instructions of how to get it all setup would be a godsend to people like me ^Ben 08:37, 23 Jul 2005 (PDT)

This is especially true with the current makefiles and such, most of it is set up for alfred reynolds computer, also it should explain that not having the exact same gclib etc will result in you wasting your time --Draco 17:07, 23 Jul 2005 (PDT)

"To have a successful multiplayer mod a Linux version of your server is a must."

I believe that line from the Article should be noted as an opinion and not fact. --wisemx 13:19, 11 Sep 2005 (PDT)

- Tweaked wording of opinion, and noted any other version than required will likely fail. As for Xerces and such, read the Xerces website? --Bloodykenny 17:38, 11 Sep 2005 (PDT)

Good change. As for Xerces, I'm the one that wrote XML code for CIMTEK, with N++. --wisemx 17:43, 11 Sep 2005 (PDT)

So if say version 2.7.0 of Xerces-c and 4.0.0 of GCC were the only ones available to us, we're screwed? I haven't had any real problems with Xercesc under Fedora Core 4, GCC on the other hand...

The problem with using different GCC versions is that Valve relies HEAVILY on sketchy/buggy code that GCC warns about in early versions, and errors out with in later versions. I've been wading through the warnings for a while trying to clean the code up to a point where I can actually trust it. Until then, anything other than the exact versions are subject to possible failure I think. --Bloodykenny 18:55, 22 Sep 2005 (PDT)

Getting the SDK ready to compile was a pain in the behind, setting up xerces and the makefile were extremely difficult. When I finally got it to spit out a ./vcpm binary, it still wanted shared librarys where they shouldn't be in the /lib folder of the root directory. Now that I got most of that mess solved, vcpm will start to run, and cause a segmentation fault, or an unhandled exception. Empires mod was going to have a linux server binary, but with this final problem, I don't think it's going to happen. --GiGaBiTe

This is the exact problem I am having. I finally got a vcpm binary built after days of messing with my Makefile. Now when I try to run vcpm, I get a "Segmentation Fault". This is extremely frustrating! --Jb55 10:19, 9 Aug 2006 (PDT)
Make sure you have either fixed the bug pointed to in the article about vcpm or done the `export LD_LIBRARY_PATH=<path>/srcds/bin/` this fixed it for me -- Khaless


Also make sure the first line in your server_hl2mp-2005.vcproj (if using VS 2005) is assigned correctly. It should be:

<?xml version="1.0" encoding="windows-1252"?>

Mine keeps reverting to:

<?xml version="1.0" encoding="windows-1250"?>
Keeper 17:43, 16 Aug 2007 (PDT)

Choice of Linux distro and software versions

I've been meaning to have a stab at compiling our Mod's code for Linux for a while now but reading the above I'm a bit twitchy about how sucessful it will be, especially with the talk of dependance on specific versions of GLIBC and GCC.

I've been looking at both Slackware 10.x and Fedora as possible starting points and have been looking at the versions shipped with them. What I've found is as follows:

  • Slackware 10.0 - GCC 3.4.0 / GLIBC 2.3.2
  • Slackware 10.1 - GCC 3.4.3 / GLIBC 2.3.4
  • Slackware 10.2 - GCC 3.4.4 / GLIBC 2.3.5
  • Fedora Core 1 - GCC 3.3.2 / GLIBC 2.3.2
  • Fedora Core 2 - GCC 3.3.3 / GLIBC 2.3.3
  • Fedora Core 3 - GCC 3.4.2 / GLIBC 2.3.3
  • Fedora Core 4 - GCC 4.0.0 / GLIBC 2.3.5
  • Fedora Core 5 - GCC 4.1.0 / GLIBC 2.4.4

Just how "sensitive" is the SDK code to the GCC/GLIB version? The statment "not having the exact same gclib etc will result in you wasting your time" is a bit disconcerting. My personal preference is to use Fedora as I have more familiarity with it and updating packages/software so I was thinking of using FC3 to keep GCC and GLIB within the 3.4.X/2.3.X version tree but to be at least the same or one higher than the recommended.

Is it even worth bothering or am I going to have to go with Slack 10.0 or FC1 and manual try and get GCC/GLIBC to 3.4.1 and 2.3.2 respectively?

With GCC, AFAIK you can go up to 4.1.x without any major problems, since the ABI didn't change. As for GLIBC, quite many systems still have 2.3 installed at the moment, so I would try toning that down slightly. You might wish to try some voodoo as demonstrated in this autopackage header, which should force the compiler to use only symbols compatible with older GLIBC versions. (This "downgrading" process is forward-compatible.)
Hope this helps. ~~Ravu 14:43, 20 Mar 2007 (PDT)
Okay, I've had no problems compiling the current SDK with 4.1 and running it as a mod. However, there might be "silent failures" happening at awkward places, so make sure you test things extensively when going for GCC4. As for GLIBC, I've finally understood how the backwards compatibility works and wrote a section on that, so feel free to read through and follow it.
Good luck. ~~Ravu 12:26, 21 Mar 2007 (PDT)
Actually in the end I used a VMWare install of Fedora core six with the compat install GCC 3.4.6. So far my mod compiles and seems to run fine with it.

Compiling witth gcc-4.1

I had troubles to get the mod running with gcc-4.1. Compiling and running with gcc-3.4 works however. For some reason hl2mp spits out 'different class tables' error if you compile it with gcc4.1 on debian lenny.

I had some trouble with Debian Lenny too, that's why i use Debian Etch x86 at the moment for Source Engine compiling (good that you can use Virtualisation nowadays for that), i would prefer to use Debian Lenny x64 (and using -m32 as gcc on x64 can compile both x64 and x86 but not via versa) for that too but since it makes trouble :/ --Neico 04:51, 22 October 2009 (UTC)

ABI documentation link was out of date; took the liberty of updating it. --Sigmaseven 22:18, 21 July 2010 (UTC)

Compiling under Ubuntu

Could I use Ubuntu? --Adam.gamedev 22:40, 30 August 2010 (UTC)

A few things

Is there any reason why all the information about compatibility with different versions of libc has been removed? The gcc requirement of 4.2.x and lower is very misleading as a numerous of versions in that range will not be very successful. --Roob 02:00, 24 June 2011 (UTC)

The libc stuff is too complex for this article. In practice everyone will want to use the oldest version after 2.4 they can, so that's what is recommended. I'm not aware of the GCC issues though, I just went on what worked and what other people (and the old page, which recommended 3.4!) were saying. --TomEdwards 10:58, 24 June 2011 (UTC)