Building GE:S on Debian / SteamOS

[mdeguzis]

#23 was for Arch Linux, so I broke this out from the conversation. If this was not the right move, I can close this thread to avoid more noise. I can't determine if this is a linking order issue, or dependency issue at the moment. ../thirdparty/boost-python/libboost_python.a libsteam_api.so libtier0.so libvstdlib.so -Wl,-rpath,/build/ges-5.0+20161024git+bsos/build/python/lib:/build/ges-5.0+20161024git+bsos/build/game is included after the linking?.

Debian progress tracker:
Reproducible steps for Debian 8 32-bit chroot :

Updated 20161024 @ 15:10 UTC -0500

sudo apt-get update
sudo apt-get install cmake libboost-all-dev libc6-dev libldap2-dev
git clone --recursive https://github.com/goldeneye-source/ges-code
cd ges-code
mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=/usr ..

• Build files
• Build log
• Generated Makefile
• build/cmake_install.cmake
• build/CMakeCache.txt
• build/python/src/python-build/CMakeCache.txt

Current problems

• None! I just don't know how to install the libraries :P
• The build notes specify -DCMAKE_INSTALL_PREFIX=[path_to_gesource], and I'm unsure what gesource refers to explicitly, unless that is the folder to the client/sever zip files?

[mdeguzis]

Got it! So there is a conflict if you build with libs existing on the system, at least in my case. I can only surmise that the python boost libs in libboost-all-dev conflicted..

As for the resultant libraries for client and server, do I need to place them in steamapps/sourcemods/gesource per the install instructions? Do I need to include files from the build source beyond these? I realize this is a bit left-field, being untested builds for Linux.

Old debian/control:

cmake,
 libboost-all-dev,
 libc6-dev,
 libldap2-dev

New debian/control

cmake,
 libboost-dev,
 libldap2-dev

Install the project...
-- Install configuration: "Release"
-- Installing: /usr/bin/server.so
-- Removed runtime path from "/usr/bin/server.so"
-- Installing: /usr/bin/client.so
-- Removed runtime path from "/usr/bin/client.so"

[ElectricPrism]

Great job! I'm not sure if it helps but the Windows installation of steamapps/sourcemods/gesource looks like this $tree

steam_apps-source-mods-windows.txt

In windows the app shows up upon rebooting the steam client in the games list

[mdeguzis]

The formatting on that paste looks really odd, it would be much better to use a paste site. Anyway, not sure either how to install in contrast to how the Windows installer did. I'll look more into it later.

[ElectricPrism]

It seems to look okay in Chrome and Sublime for me, I wonder why.

"As for the resultant libraries for client and server, do I need to place them in Steam/steamapps/sourcemods/gesource per the install instructions?"

That's my understanding, yes -- I even copied WINE files to my linux steam directory and Steam picked up GE:S, I then merged the new files over the old files (I know it's hackerish) - I'm assuming some of the build files would be OS agnostic, objects, textures, sound, etc...

I have yet to build both the server and client, (the server has more trouble building)

"Do I need to include files from the build source beyond these"

Possibly, the windows version contains "467 directories, 22,223 files" so I'm going to take a wild guess it should have a similar count if you don't need to merge from WINE in the package creation.

[ElectricPrism]

I wanted to confirm - you were able to resolve some build errors when system python and system boost were not present?

System Boost & Python created conflicts?

[mdeguzis]

Yes, per the above post, everything builds if you remove the conflicting libs from libboost-all-dev for Debian / SteamOS. It is very easy to setup a clean chroot for Arch Linux. I would suggest that for the best results. Let's not get off topic for this thread though. For Debian, it appears including the python libs for boost in libboost-all-dev would conflict in some manor, as it stands. What I believe happens, is the build picks up the presence of those system libs, tries to use them, and encounters a linking error, as they are not defined. The build as it stands, expects to build python and associated libs itself. That's as much as I gather at the moment. I am not a dev, so just from observation.

The next step at this stage, is figuring out exactly what is needed to included with the generated server.so and client.so libs that are built. I hope a dev will chime in. If, like I read before, there are still issues using this with Source SDK 2007, i'll patiently wait until the 2013 transition.

[droidmonkey]

This build is ONLY for SDK 2013.

[mdeguzis]

Ah ok, thank you for confirming. I read in posts that 5.1 would be, but I did not know that develop here was already building. Is there a basic 1,2,3 post build for Linux folks? I understand the libs need to go to into the gesource directory, but the contents of which I don't know beyond what the Windows installer puts there on a test VM I used.

[droidmonkey]

Unfortunately you need to tweak a few files in the actual resource directory in order to be successful on 2013. Namely the gameinfo.txt file.

[mdeguzis]

I'll be patent then for instructions on how to do that. I don't mind doing documentation at all, but in a bit naive on this particular project with Linux. If you do offer any instructions, I'll be glad to test on a few distros for you (Arch/Debian/SteamOS at the least).

[mdeguzis]

@ElectricPrism, I setup automatic continuous integration testing (See: #26). The only build so far that fails in the list, is Ubuntu. Otherwise, it appears builds function on Debian 8 32 bit and Fedora 24 32 bit.

Update: per the docker image for ubuntu I am using, the container is not 32 bit, which explains that. I will work on generating one to test with, or find an alternate.

Update2: found a an alternate docker image for i386 ubuntu that builds correctly. Travis CI testing complete for Ubuntu/Debian/Fedora. More can be added if need be.

[ElectricPrism]

@ProfessorKaos64 - I've been watching your repositories and github threads, that's great.

Your work with Travis CI looks good (I'm new to Travis).

A. What kind of file tree is created when it builds correctly? Is it still just a few or is it the full 22,691

B. Is a 32-bit Arch even possible for Travis?

C. Would it be better to alter the PKGBUILD to simply import whatever .deb or .rpm once that's done.

Great work 👍

[mdeguzis]

This is closed from my perspective until actual implementation instructions with the resulting server.so and client.so libs are posted or explained. I should note that while Debian Jessie / SteamOS builds, the Ubuntu build does not complete. See the travis builds in my fork for more.

@ElectricPrism I could always output the dir tree at the end of the build script, or just check once if you are curious. Yes I did build a 32 bit chroot for Arch Linux, then used a little magic to get that into docker. uname reports 64 bit inside the docker container, but it is not (as pacman confs etc show i686 configurations). I just made that, so there may be adjustments with it, but it seems to work. I tried it on a 32bit only AUR build and installing packages pulls in i686 variants. The base image is larger than some, but given the method used to create it, and being a full base system, it's about right.

See: https://github.com/ProfessorKaos64/arch-scratch
See: https://hub.docker.com/r/professorkaos64/arch-scratch/