Help Building on Arch

[ElectricPrism]

Here's what I do:

mkdir ~/Builds
cd ~/Builds

git clone https://github.com/goldeneye-source/ges-code.git

cd ges-code

mkdir build && cd build

cmake -DCMAKE_INSTALL_PREFIX=/usr ..

Here's the output:

➜  build git:(develop) cmake -DCMAKE_INSTALL_PREFIX=/usr ..
-- Boost version: 1.61.0
CMake Error at /usr/share/cmake-3.6/Modules/ExternalProject.cmake:1924 (message):
  No download info given for 'python' and its source directory:

   /home/electricprism/Builds/ges-code/thirdparty/python

  is not an existing non-empty directory.  Please specify one of:

   * SOURCE_DIR with an existing non-empty directory
   * URL
   * GIT_REPOSITORY
   * HG_REPOSITORY
   * CVS_REPOSITORY and CVS_MODULE
   * SVN_REVISION
   * DOWNLOAD_COMMAND
Call Stack (most recent call first):
  /usr/share/cmake-3.6/Modules/ExternalProject.cmake:2473 (_ep_add_download_command)
  CMakeLists.txt:49 (ExternalProject_Add)

-- Configuring incomplete, errors occurred!
See also "/home/electricprism/Builds/ges-code/build/CMakeFiles/CMakeOutput.log".

What does this mean and how do I fix it?

[z33ky]

You need to git clone --recursive, or now that you've already cloned the repository just do git submodule init --recursive.

[droidmonkey]

ah yes, oops forgot about init submodules, I'll fix the readme

[droidmonkey]

I'll leave this open in case you have further difficulties

[mdeguzis]

Trying to build this on Debian Jessie. Does this require gcc 5.0+? If so, can it be built with clang? When building I did get some initial errors about missing sys/cdefs.h, which was resolved installing libc6-dev:i386, for one.

So far, on a Debian system, these are needed:

cmake
libboost-all-dev
libc6-dev:i386
libstdc++-4.9-dev:i386

So far, my build stops here (cmake completes, make output below):

http://sprunge.us/NKFF

[mdeguzis]

For some reason, when make is issued, the Makefile generated by cmake tries to use /usr/bin/cc

make -C build
make[2]: Entering directory '/tmp/buildd/ges-5.0+20161023git+bsos/build'
make[3]: Entering directory '/tmp/buildd/ges-5.0+20161023git+bsos/build'
make[4]: Entering directory '/tmp/buildd/ges-5.0+20161023git+bsos/build'
Scanning dependencies of target python
make[4]: Leaving directory '/tmp/buildd/ges-5.0+20161023git+bsos/build'
make[4]: Entering directory '/tmp/buildd/ges-5.0+20161023git+bsos/build'
[  0%] Creating directories for 'python'
[  0%] No download step for 'python'
[  0%] No patch step for 'python'
[  0%] No update step for 'python'
[  0%] Performing configure step for 'python'
loading initial cache file /tmp/buildd/ges-5.0+20161023git+bsos/cmake/ges_python.cmake
-- The C compiler identification is GNU 4.9.2
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- broken

The full build log is above.

[mdeguzis]

Ok the build works it seems with clang (in my test, 3.8). I had to link /usr/bin/cc to /usr/bin/clang-3.8. I'm sure there is a clean way to update the /usr/bin/cc alternative, so that was just a test. gcc 4.9 must be too old it seems. Not sure why python 3.5 has to download each time. Maybe there is a check on 3.5+? My repository sources have 3.4 but it still downloads it.

[ElectricPrism]

I tried again using the git --recursive option as suggested by @z33ky - thanks :)

Dependencies sudo pacman -S boost boost-libs cmake gcc-multilib

I try this

sudo pacman -S boost boost-libs cmake

mkdir ~/Builds

cd ~/Builds

git clone --recursive https://github.com/goldeneye-source/ges-code.git

cd ges-code && mkdir build && cd build

cmake -DCMAKE_INSTALL_PREFIX=/usr ..

make install

I get this

-- Checking for XOPEN_SOURCE
-- Checking for XOPEN_SOURCE - yes
-- Checking for Large File Support
-- Checking for Large File Support - yes
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - failed
-- Check size of unsigned int
-- Check size of unsigned int - failed
-- Check size of unsigned long
-- Check size of unsigned long - failed
CMake Error at /usr/share/cmake-3.6/Modules/TestBigEndian.cmake:51 (message):
  no suitable type found
Call Stack (most recent call first):
  cmake/ConfigureChecks.cmake:582 (TEST_BIG_ENDIAN)
  CMakeLists.txt:298 (include)

-- Configuring incomplete, errors occurred!
See also "/home/electricprism/Builds/ges-code/build/python/src/python-build/CMakeFiles/CMakeOutput.log".
See also "/home/electricprism/Builds/ges-code/build/python/src/python-build/CMakeFiles/CMakeError.log".
make[2]: *** [CMakeFiles/python.dir/build.make:106: python/src/python-stamp/python-configure] Error 1
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/python.dir/all] Error 2
make: *** [Makefile:128: all] Error 2

Full Log

I'm running gcc (GCC) 6.2.1 20160830

[ElectricPrism]

Progress update - I was able to pass the 100% compile mark before running into what looked like errors linking to 32-bit system libraries.

I removed boost-python and python from he ges-code/CMakeLists.txt file and commented out compiling the server as it had some error in ges-code/game/CMakeLists.txt line 79 to 113.

Here's what I did

# Add Key to Install from AUR
gpg --keyserver keyserver.ubuntu.com --recv 8FE99503132D7742

# Install lzlib
yaourt -S lzlib

# Manual Link (Is this a 32-bit fix for Arch?)
sudo ln -s /usr/lib/libz.so.1.2.8 /usr/lib/libzlib.so

# Enable Clang
ln -sf /usr/bin/cc /usr/bin/clang

# Confirm
ls -la /usr/bin/cc

# Test Output to make sure it produces no errors at the end
ld -lzlib --verbose

# Install what I think the dependencies are on Arch
sudo pacman -S boost boost-libs cmake glibc lib32-glibc libstdc++5 lib32-libstdc++5 opencv base-devel

# This is a good place to build stuff
mkdir -p ~/Builds && cd ~/Builds

# Clone the repository and dependencies
git clone --recursive https://github.com/goldeneye-source/ges-code.git

# Enter new build directory
cd ges-code && mkdir build && cd build

# CMake
cmake -DCMAKE_INSTALL_PREFIX=/usr ..

# Make Install
make install

# Related Problem Notes From Google?
I had the same problem and my solution is remove all build file (or CMakeCache.txt) and cmake again.

The problem is that cmake finds a 32-bit library rather than the 64-bit one, which should be found in /lib64/libbz2.so or /usr/lib64/libbz2.so. Sometimes the cmake get messed up and keep using the cached variable. So if you remove the cache and cmake again, it should find the correct library.

Here was the last bit of output SNIP

I was able to build the 64-bit version easier so my current plan is to remove "-m32" flags from the project and try again to see if it will build.

Attached is my custom CMakeLists.txt ges-code/CMakeLists.txt

[ElectricPrism]

I've built it on Arch it requires Python 3.4, It won't build against Python 3.5, here's a tree of the layout of what's built

ges-tree.txt

[0xBADEAFFE]

@ElectricPrism how did you force python-cmake to download and build python 3.4?

[ElectricPrism]

Build Instructions

I use gcc-multilib, python34 [AUR], boost, boost-libs lib32-glibc, etc...

# GES Prefers Python 3.4
yaourt -S python34

# Install what I think the dependencies are on Arch
sudo pacman -S boost boost-libs cmake glibc lib32-glibc libstdc++5 lib32-libstdc++5 opencv base-devel openldap gcc-multilib steam-native-runtime

# This is a good place to build stuff
mkdir -p ~/Builds && cd ~/Builds

# Clone the repository and dependencies
git clone --recursive https://github.com/goldeneye-source/ges-code.git

# Enter project directory
cd ges-code

# Backup
mv CMakeLists.txt CMakeLists.txt.bak

# Replace $PROJECT/CMakeLists.txt with the attached file eg:
wget https://github.com/goldeneye-source/ges-code/files/547345/CMakeLists-electricprism-2016-10-24-02-24.txt

# Supplement my CMakeLists.txt 
mv CMakeLists-electricprism-2016-10-24-02-24.txt CMakeLists.txt

# !!!! Before you run make install you have to edit $PROJECT/game/CMakeLists.txt and comment out the SERVER_BUILD from line 79 - 114. !!!!

# Enter game directory
cd game

# Backup CMakeLists.txt
mv CMakeLists.txt CMakeLists.txt.bak

# Download new version
wget https://github.com/goldeneye-source/ges-code/files/547365/CMakeLists-game-electricprism-2016-10-24-02-32.txt

# Supplement new version
mv CMakeLists-game-electricprism-2016-10-24-02-32.txt CMakeLists.txt

# Move up directory
cd ..

# Create Build Directory and Enter
mkdir build && cd build

# CMake
cmake -DCMAKE_INSTALL_PREFIX=/usr ..

# Make Install
make install

CMakeLists-electricprism-2016-10-24-02-24.txt

CMakeLists-game-electricprism-2016-10-24-02-32.txt

[ElectricPrism]

"how did you force python-cmake to download and build python 3.4?"

@vincent-t - I downloaded python 3.4 via my package manager - Yaourt aka:

yaourt -S python34

In my situation I have both Python 3.4 and 3.5 installed side by side.

[ElectricPrism]

@vincent-t - The output of the build was confusing to me, or maybe its just getting late, the wife and I gotta sleep, gonna pick this back up tomorrow.

Here's what $PROJECT/build/game containd -- I have yet to figure out what to do with it https://drive.google.com/open?id=0BzWyc39KQnJONU5RRjhnclROZVU

It's my understanding that the mod should install to ~/.local/share/Steam/steamapps/sourcemods/gesource

If you learn anything new let me know, and let me know how it goes :) cheers

[droidmonkey]

You guys are both putting in way too much effort on this.

First off, this MUST be built as 32-bit (which the CMAKE script does for you. Valve does not support 64-bit Linux as all of their platform libraries in the SDK-2013 are 32-bit.

Second,

HAVE_LIBM
HAVE_LIBUTIL

Means you are missing critical libraries in order to build properly. You need to have libm dev and libutil dev installed on your system.

This builds great running Fedora 24 x64 with all pre-reqs installed.

Thirdly, Python library is downloading ONCE unless you perform a make clean or build in a different folder, then it'll download it again. The download and build of python is cached in your build folder.

[mdeguzis]

@droidmonkey, for the uninitiated with building Source SDK projects, some of us just didn't know that. I use pbuilder/mock, so I now made sure to use a 32 bit chroot and things are building great. The question still remains though, why is python always being downloaded? Does it need 3.5.2+ specifically, or is it compiled every time for consistency? I don't build locally for many good reasons. I'll post the full list once I work out the entire build. I had my build stop not finding -lldap with ld. The checks for the libraries should stop cold if libs are not found. checking for ... -failed, exit. I would also list make then make install for the build instructions.

Also everyone posting huge code snippets, use a paste bin, please*.

[droidmonkey]

Python is download prior to building for the first time because of consistency in the process. Before, we provided prebuilt Python that was not portable across build envs. If you maintain your build directory it SHOULD NOT download everytime you make.

The cmake scripts could use some more upfront prerequisite checking, but hey it's a strong start, gimme some cred for cleaning up Valve's atrocious build process with the sdk runtime.

[mdeguzis]

@droidmonkey , i'm sorry I came across that way, I IMMENSELY appreciate this! I play on maintaining an Arch AUR / Debian package once I work out the smaller details here.

Current build script with Debian Jessie (verbose make): http://sprunge.us/cUIT. If anyone is interested, by in progress Debian build files are here.

Have some ld errors to work through yet (pyexpat/zlib). For those on this thread using "VERBOSE=1" or "V=1" with make will expose commands to work through any problems you have linking. Perhaps I should just drop including libexpat/zlib in the build. Sometimes, I believe linker ordering (-l ) causes this. hmm. This is why I build with a clean chroot, to iron out these things. I'll try building without expat/zlib in my package lists. Listing the packages you installed in a clean chroot / VM would help several here as well.

The line of the build log for that is:

CMakeFiles/server.dir/server/ges/py/ge_pyweapon.cpp.o  -L/build/ges-5.0+20161024git+bsos/build/python/lib -m32 -Wl,--no-undefined ../../lib/public/linux32/libparticles.a ../../lib/public/linux32/libmathlib.a ../../lib/common/linux32/libcurl.a ../../lib/public/linux32/libdmxloader.a ../../lib/public/linux32/libchoreoobjects.a ../tier1/libtier1.a ../../lib/public/linux32/libtier2.a ../../lib/public/linux32/libtier3.a ../../lib/public/linux32/libz.a -lm -ldl -lpthread -lldap -lrt -lutil -lnsl -lpython3.5m ../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: 

I can fork and create a Travis CI config file. Once that is working, that would be a good indicator of a working build for continuous integration testing with Linux folks.

[droidmonkey]

Hah no worries. Travis would be good, but I hate that they are stuck on Ubuntu 14.04 and their builds are slower than mud...

Jenkins might be more appropriate to allow for local CI with reporting.

[mdeguzis]

I am missing some libs yet. Upon checking the code, folks here should be aware that libm is for libmagic*. It could be that the undefined references are due to including too many packages, and libexpat/zlib was being picked up since I included it, but not defined in the linker. I'd imagine though that having those in your system for a local build would cause those issues on Debian derivatives though. If they are permitted, i'd think that they would need an additional -L<path>. I'm not a developer though :)

It would possibly beneficial for some if you list your Fedora packages you installed.

[ElectricPrism]

git submodule init --recursive

This doesn't work

sage: git submodule [--quiet] add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--] <repository> [<path>]
   or: git submodule [--quiet] status [--cached] [--recursive] [--] [<path>...]
   or: git submodule [--quiet] init [--] [<path>...]
   or: git submodule [--quiet] deinit [-f|--force] (--all| [--] <path>...)
   or: git submodule [--quiet] update [--init] [--remote] [-N|--no-fetch] [-f|--force] [--checkout|--merge|--rebase] [--[no-]recommend-shallow] [--reference <repository>] [--recursive] [--] [<path>...]
   or: git submodule [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
   or: git submodule [--quiet] foreach [--recursive] <command>
   or: git submodule [--quiet] sync [--recursive] [--] [<path>...]

Instead this works

git submodule update --init --recursive

I'm determined to get as far as I can, if some of my choices seem noobish please forgive me as I'm new at this.

I'm writing a PKGBUILD right now for [AUR] to see if I can get it to autocompile - I'll post it if I get it into pretty good shape.

[ElectricPrism]

I'm going to take a break. I did start to convert my installation instructions into a PKGBUILD. It's working on my system currently, however I'm sure I'll have to revise it to figure out how to get the server part in /game/server to compile

# Maintainer: Electric Prism <electricprism@gmail.com>
# Contributor: Electric Prism <electricprism@gmail.com>

pkgname=ges-git
pkgver=5.0.99
pkgrel=1
pkgdesc='Multiplayer Only FPS. A recreation of GoldenEye64 as a Half-Life 2 mod using thing Source Engine SDK 2013.'
arch=('i686' 'x86_64')
url='https://www.geshl2.com/'
license=('Unknown' 'GPL')
depends=('boost' 'boost-libs' 'python' 'glibc' 'lib32-glibc' 'libstdc++5' 'lib32-libstdc++5' 'opencv')
makedepends=('cmake' 'git' 'gcc-multilib' 'openldap')
optdepends=('steam-native-runtime')
options=('!emptydirs')
source=('ges-git::git+https://github.com/goldeneye-source/ges-code.git')
sha256sums=('SKIP')

provides=('ges-git')
conflicts=('ges-git')

#pkgver() {
#  cd ges-code
#
#  git describe | sed 's/-/.r/; s/-g/./'
#}

prepare() {
    cd "${srcdir}/${pkgname}"

    # Delete previous existing builds
    if [[ -d build ]]; then
        rm -rf build
    fi

    # Create build dir
    mkdir build
}

build() {

    # Enter git root
    cd "${srcdir}/${pkgname}"

    # Initialize submodules
    git submodule update --init --recursive

    # Backup
    mv CMakeLists.txt CMakeLists.txt.bak

    # Replace $PROJECT/CMakeLists.txt with the attached file eg:
    wget https://github.com/goldeneye-source/ges-code/files/547345/CMakeLists-electricprism-2016-10-24-02-24.txt

    # Supplement my CMakeLists.txt 
    mv CMakeLists-electricprism-2016-10-24-02-24.txt CMakeLists.txt

    # Enter game directory
 cd "${srcdir}/${pkgname}/game"

    # Backup CMakeLists.txt
    mv CMakeLists.txt CMakeLists.txt.bak

    # Download new version
    wget https://github.com/goldeneye-source/ges-code/files/547365/CMakeLists-game-electricprism-2016-10-24-02-32.txt

    # Supplement new version
    mv CMakeLists-game-electricprism-2016-10-24-02-32.txt CMakeLists.txt

    # Enter build directory
    cd "${srcdir}/${pkgname}/build"

    cmake -DCMAKE_INSTALL_PREFIX=~/.local/share/Steam/steamapps/sourcemods/gesource ..
}

package() {
    cd "${srcdir}/${pkgname}"/build 
    make DESTDIR="${pkgdir}" install
}

copy PKGBUILD to ~/Builds/ges/

Compile .tar.xz for pacman to merge using pacman -U makepkg -s

[ElectricPrism]

Line 25 and 26 of CMakeLists.txt seems to set the compiler to target Intel Core 2 Duo with the core2 flag on -march and -mtune

  add_compile_options(-w -std=gnu++0x -fpermissive -fno-strict-aliasing -ffast-math -fno-omit-frame-pointer
    -ftree-vectorize -fpredictive-commoning -funswitch-loops -m32 -march=core2 -mtune=core2 -msse2 -mfpmath=sse)

Shouldn't it be set to i686 because the binary built should be 32-bit?

[0xBADEAFFE]

No the -m32 flag sets the architecture. ;)

[ElectricPrism]

Thanks, I've started to organize my efforts over here: https://github.com/ElectricPrism/aur-ges

[mdeguzis]

That should be noted in the readme. Also, building in a clean chroot will indicate you also need other libs for bzip2, expat, zlib, etc..

On October 24, 2016 6:56:29 AM EDT, Jonathan White notifications@github.com wrote:

You guys are both putting in way too much effort on this.

First off, this MUST be built as 32-bit (which the CMAKE script does for you. Valve does not support 64-bit Linux as all of their platform libraries in the SDK-2013 are 32-bit.

Second,

HAVE_LIBM
HAVE_LIBUTIL

Means you are missing critical libraries in order to build properly. You need to have libm dev and libutil dev installed on your system.

This builds great running Fedora 24 x64 with all pre-reqs installed.

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/goldeneye-source/ges-code/issues/23#issuecomment-255709634

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[mdeguzis]

I never built a Source SDK release project, so pardon me. I use pbuilder as well. I'll adjust to build in a 32 bit chroot and add those libs. I assume you build with mock or local with rpmbuild. Thank you.

On October 24, 2016 6:56:29 AM EDT, Jonathan White notifications@github.com wrote:

You guys are both putting in way too much effort on this.

First off, this MUST be built as 32-bit (which the CMAKE script does for you. Valve does not support 64-bit Linux as all of their platform libraries in the SDK-2013 are 32-bit.

Second,

HAVE_LIBM
HAVE_LIBUTIL

Means you are missing critical libraries in order to build properly. You need to have libm dev and libutil dev installed on your system.

This builds great running Fedora 24 x64 with all pre-reqs installed.

You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/goldeneye-source/ges-code/issues/23#issuecomment-255709634

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[ElectricPrism]

@ProfessorKaos64 - The readme technically needs work as it is as the git submodule init command is incomplete. I had to search for a similar version and came up with git submodule update --init --recursive

I unfortunately am not a Level 60 compiler mage, and I've only ever built very few things (No Source SDK either.)

Could you link me or dump a list of dependencies you've found here? Thanks

On arch I've started to build with extra-i686-build instead of makepkg -s as it seems to create a clean 32-bit chroot for the build process.

I'm not sure why but it seems like game/CMakeLists.txt also needs to be modified as it's trying to link to boost and failing on vanilla.

droidmonkey said it compiles on Fedora - It might be awkward but I wonder if it'll compile to something usable and then the RPM or whatever could be exploded and repackaged into .dev and whatever else if that's the case.

[droidmonkey]

I'll work on attempting a compile on another platform and document my mage skillz. Thanks for keeping this alive, I honestly have not ported it to any other platforms besides Fedora.

[mdeguzis]

@ElectricPrism , I typically just use git clone --recursive , but you should just follow the proper update/init routines with git, outlined in the AUR guideline for VCS. I always follow that for my AUR packages. In my case on my OS, including those extra system libs then tries to link them later on. Follow my advice and setup a clean chroot for bulding. I was planning on submitted an AUR package later on, but if you intend to, follow the Arch Linux guidelines for a git package.

Edit: Sorry, here is the Arch Linux page for building in a clean i686 chroot.

[mdeguzis]

I'm going to keep working to see if I can build this with a vanilla clone of the repo vs. the fork / modifications ElectricPrism made and his fork of the repo. The undefined references, like my Debian/SteamOS build, is conflicting with system libs (at least it seems). I'll try adding options to ges_python.cmake to disable sqlite/zlib etc, as it seems those are having issues.

• Arch Linux build log from clean 32-bit chroot
• PKGBUILD (vanilla build)

What is the danger of just using a distro's python 3.5+ (assuming the build works)?

[ElectricPrism]

@ProfessorKaos64 You probably would be better suited to make the AUR than me since It would be my first submission but I wanted to grow my skills in developing PKGBUILD's.

From building in the i686 chroot it seemed that the CMakeLists.txt for some reason wasn't recognizing where the Boost_ Include directory was? I think it might need to be manually declared somewhere before or near find_package(), and also I'm not sure but the current Boost Libraries is version 1.61 on Arch whereas the CMake asks for 1.52, I'm not sure if it looks for that exact version or up?

I'll do my best to take your instructions and document them I have both a aur-ges and ges-code repo where I'm logging my work.

I'm very excited for us and the progress & work you're doing - when its all finalized we can hit up gamingonlinux.com and I'm sure they'll give GE:S a bunch of Linux gamers to come and enjoy with us all :)

[mdeguzis]

You can't work around the linking issues it seems, like I did by just not including extra packages on Debian 8 / SteamOS. If you disable zlib,sqlite, or gdbm modules (forgive if the yare required, just testing around), you get this error and set of link flags:

-lm -lm -lm -lnsl -lm -lexpat -lexpat -lz -lgdbm -lgdbm_compat -lreadline -lcurses -lform -lsqlite3 -lz -ldl -lutil -lm -lnsl -lexpat -lz -lgdbm -lgdbm_compat -lreadline -lcurses -lform -lsqlite3 -ldl -lutil 
CMakeFiles/_freeze_importlib.dir/__/__/CMakeFiles/config.c.o:(.data+0x21c): undefined reference to `PyInit_dbm'

Regardless of this test being wrong or right, that is one strange set of linker flags. So many duplicates. I suppose I'll try turning off/on using system versions of an libs mentioned above.

[mdeguzis]

The 32 bit Arch Linux build via Travis CI / docker gets father now after the latest 20161101 commit. I noticed the CI build didn't die after 16 minutes :)

See: https://travis-ci.org/ProfessorKaos64/ges-code/jobs/176164141

[Enverex]

Is there an option to tell the build to use the system version of Python rather than trying to use the bundled one? (where is where all the errors appear to come from at the end right now).

[ElectricPrism]

@mdeguzis Do you have a link to your current build instructions, I'm curious to see if anything has changed and if it will get farther or not.

@Enverex I personally had to manually disable GES python, maybe @droidmonkey knows of a better way to enable/disable to use system python.

[droidmonkey]

If you want to use system python then you need to replace the section in cmakelists.txt regarding python project with a simple find_library call.

[pidario]

Sorry for necro-bumping this thread after all these years, but since it's still flagged as open I guess I'll take my shot. Has anybody ever managed to build it? This repo https://github.com/droidmonkey/python-cmake-buildsystem.git doesn't even exist anymore (possibly moved to https://github.com/python-cmake-buildsystem/python-cmake-buildsystem). What path are you supposed to use for the cmake argument (-DCMAKE_INSTALL_PREFIX)? I guess it's the path of the gesource folder that I had previously downloaded via torrent. Anyhow, I fixed the missing submodule, run cmake -DCMAKE_INSTALL_PREFIX=/path/to/gesource .. from the build directory I created inside the project root and than make install. It goes for some time but eventually it stops with this error:

/usr/bin/ld: /usr/lib/libnsl.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
make[5]: *** [CMakeBuild/libpython/CMakeFiles/_freeze_importlib.dir/build.make:3327: CMakeBuild/libpython/_freeze_importlib] Error 1
make[4]: *** [CMakeFiles/Makefile2:1112: CMakeBuild/libpython/CMakeFiles/_freeze_importlib.dir/all] Error
2
make[3]: *** [Makefile:146: all] Error 2
make[2]: *** [CMakeFiles/python.dir/build.make:102: python/src/python-stamp/python-install] Error 2
make[1]: *** [CMakeFiles/Makefile2:156: CMakeFiles/python.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

I'm not a C/C++ guru so please, help me and the linux community to build this awesome game. Thanks in advance P.S: I use arch too, btw :D

[droidmonkey]

This project hasn't been touched in 6 years or so. Recommend using vcpkg now adays as that is the modern way to handle dependencies.

[pidario]

As I said, I'm not an expert but it doesn't look like a dependency issue. Anyway, thanks for the tip, I'll try.