Talk:Compiling under Linux

From Valve Developer Community
Revision as of 19:26, 21 March 2007 by RavuAlHemio (talk | contribs)

Jump to: navigation, search

Maybe a more indepth tutorial including how to install Xerces XML parser 2.6.0 or above ( ). Because I am stumped when I try to install that.

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

Can someone explain what

 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. 

Actually means? How would I go around "removing the rest"? --Garry Newman 12:36, 6 Nov 2005 (PST)

See file just added to article. --Bloodykenny 20:58, 7 May 2006 (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)