Linux build

[flibitijibibo]

Whuh oh.

https://github.com/SuperV1234/SSVOpenHexagon/commit/9728779fe9154e66a78aa9be1cad44be056244f6

Just to be sure, Arch does /usr/include/jsoncpp/json/ too, right? Rather than /usr/include/jsoncpp/ alone?

[Mischa-Alff]

Arch has no official jsoncpp package as far as I'm concerned. There's always the AUR package (Arch User Repositories), which installs it to /usr/include/jsoncpp/json/, but the package uses the latest stable release, not 0.6.0-rc. I thus installed jsoncpp manually using https://github.com/mrtazz/json-cpp, which doesn't actually install, it just builds, so I manually installed it to /usr/include/jsoncpp/. I now realize how much of a mess jsoncpp is.

[Mischa-Alff]

Anyways, I do think it would be much better to use a header-only version of the library ( https://github.com/xushiwei/jsoncpp/tree/master/include/json ). Like that, the users can keep their own install directory, and we won't have to worry about it. Sure, it /could/ raise the compile time by a few seconds, but that's not much of an issue. Even though the last commit for that code is.. a year ago, the 0.6.0 rc hasn't been updated since 2011, so I think using that library would be safe. If SuperV1234 would acknowledge and implement, that would be great. This would also be the perfect occasion to use this as a submodule.

[flibitijibibo]

Just saw the new project, will this mean that OpenHexagon-Unix is no longer needed?

[vittorioromeo]

I don't know if it's still needed, but CMake building >should< work on Linux. It would be great if you could still build binaries using the existing CMake, as I still use Windows as my development environment.

[flibitijibibo]

From an F17 setup with lua-devel and jsoncpp-devel installed:

-- The C compiler identification is GNU 4.7.2
-- The CXX compiler identification is GNU 4.7.2
-- Check for working C compiler: /usr/lib64/ccache/gcc
-- Check for working C compiler: /usr/lib64/ccache/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/lib64/ccache/c++
-- Check for working CXX compiler: /usr/lib64/ccache/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done

Found JsonCpp include at: JSONCPP_INCLUDE_DIR-NOTFOUND.

Found JsonCpp library at: JSONCPP_LIBRARY-NOTFOUND.

-> JsonCpp directory not found. Set SSVUTILS_ROOT to SSVUtils' top-level path (containing both "include" and "lib" directories).
SFML found but version too low (requested: 2, found: 1.x)

-> SFML directory not found. Set include and libraries manually.

Found SSVUtils include at: /home/flibitijibibo/Programming/cppProjects/OpenHexagon/SSVOpenHexagon/extlibs/SSVUtils/include.

Found SSVUtils release library at: SSVUTILS_LIBRARY_RELEASE-NOTFOUND.

Found SSVUtils debug library at: SSVUTILS_LIBRARY_DEBUG-NOTFOUND.

-> SSVUtils directory not found. Set SSVUTILS_ROOT to SSVUtils' top-level path (containing both "include" and "lib" directories).

Found SSVUtilsJson include at: /home/flibitijibibo/Programming/cppProjects/OpenHexagon/SSVOpenHexagon/extlibs/SSVUtilsJson/include.

Found SSVUtilsJson library at: SSVUTILSJSON_LIBRARY-NOTFOUND.

Found SSVStart include at: /home/flibitijibibo/Programming/cppProjects/OpenHexagon/SSVOpenHexagon/extlibs/SSVStart/include.

Found SSVStart release library at: SSVSTART_LIBRARY_RELEASE-NOTFOUND.

Found SSVStart debug library at: SSVSTART_LIBRARY_DEBUG-NOTFOUND.

-> SSVStart directory not found. Set SSVSTART_ROOT to SSVStart' top-level path (containing both "include" and "lib" directories).

Found SSVEntitySystem include at: /home/flibitijibibo/Programming/cppProjects/OpenHexagon/SSVOpenHexagon/extlibs/SSVEntitySystem/include.

Found SSVEntitySystem release library at: SSVENTITYSYSTEM_LIBRARY_RELEASE-NOTFOUND.

Found SSVEntitySystem debug library at: SSVENTITYSYSTEM_LIBRARY_DEBUG-NOTFOUND.

-> SSVEntitySystem directory not found. Set SSVENTITYSYSTEM_ROOT to SSVEntitySystem' top-level path (containing both "include" and "lib" directories).

Found Lua include at: LUA_INCLUDE_DIR-NOTFOUND.

Found Lua library at: /usr/lib64/liblua.so.

CMake Error at cmake/FindLUA.cmake:50 (MESSAGE):
  Could not find LUA library
Call Stack (most recent call first):
  CMakeLists.txt:36 (find_package)

-- Configuring incomplete, errors occurred!

I'd worry more about getting a build server to do this though, since SFML2 is almost certainly not going to be in a typical distro's repository anyway.

[vittorioromeo]

Have you pulled the latest cmake changes? I'd like to know if they fix the problem.

[flibitijibibo]

Yup, that output's from the current revision.

[vittorioromeo]

Have you compiled the extlibs first? The current CMake files require you to build extlibs first, then run the Open Hexagon CMakeLists.

[flibitijibibo]

Ah, fair enough. I'll wait for a build.sh then.

[Mischa-Alff]

Wouldn't a build.sh (or .bat) kill the point of CMake? My opinion about cmake is just doing cmake .; make; sudo make install;, and nothing more. If the user has to build each dependency independently from Open Hexagon, even if they're all submodules, then what's the point of submodules? Why not just give the user a dependencies.txt full of git repositories? (I'm obviously exaggerating here, but I hope you get my point).

[flibitijibibo]

I think the point is to make all of the SSV libraries... well, libraries, then build OpenHexagon against those, rather than having it all be one engine with components. OpenHexagon-Unix took the latter category, mostly because "I just could", rather than it being the actual design of the codebase.

[Mischa-Alff]

Dunno, I just find it much more practical to build all of the dependencies and the main target in one command.

[vittorioromeo]

@flibitijibibo Hi Ethan, I have a problem: I want to make a .tar.gz package with compiled 32-bit binaries for Open Hexagon for Linux.

I want the .tar.gz to work by simply extracting it somewhere and running the game executable.

• My current setup is Linux Mint 15 x64 - how can I compile a 32-bit version of the game?
• The game, as you already know, uses a lot of shared library dependencies - I want to put them in the .tar.gz, maybe under a subfolder. How can I tell the executable to look for shared libraries not in /usr/lib/ (or whatever) but in ./dependencies/ (for example)?

Thanks

[flibitijibibo]

To force 32-bit compilation, use gcc flag -m32. For instance, gcc -m32 -o program.x86 main.c.

Check out my old distributions of OpenHexagon for how to distribute the game with deps and multiple architectures. I use a launch script 'OpenHexagon' and two folders, 'x86/' and 'x86_64/'.

[vittorioromeo]

@flibitijibibo, thanks for the reply. I've created a test 64-bit .tar.gz (http://vittorioromeo.info/Misc/Temp/linuxtest64OpenHexagon1.92.tar.gz) including the following libs:

libfreetype.so.6 liblua5.1.so.0 libsfml-graphics.so.2 libsfml-window.so.2 libSSVLuaWrapper.so libSSVUtilsJson.so openhexagon.x86_64 libGLEW.so.1.8 libopenal.so.1.14.0 libsfml-network.so.2 libSSVEntitySystem.so libSSVMenuSystem.so libSSVUtils.so libjpeg.so.8 libsfml-audio.so.2 libsfml-system.so.2 libSSVJsonCpp.so libSSVStart.so libstdc++.so.6

But users report this error:

~/Arbeitsfläche/OpenHexagon1.92$ ./OpenHexagon ./x86_64/openhexagon.x86_64: /usr/lib/x86_64-linux-gnu/./libstdc++.so.6: version GLIBCXX_3.4.18' not found (required by ./x86_64/openhexagon.x86_64) ./x86_64/openhexagon.x86_64: /usr/lib/x86_64-linux-gnu/./libstdc++.so.6: versionGLIBCXX_3.4.19' not found (required by x86_64/libSSVUtils.so) ./x86_64/openhexagon.x86_64: /usr/lib/x86_64-linux-gnu/./libstdc++.so.6: version GLIBCXX_3.4.18' not found (required by x86_64/libSSVStart.so) ./x86_64/openhexagon.x86_64: /usr/lib/x86_64-linux-gnu/./libstdc++.so.6: versionGLIBCXX_3.4.18' not found (required by x86_64/libSSVEntitySystem.so)

I can't find any GLIBCXX to put in the .tar.gz, and it seems that what's really needed is libstdc++.so.6, but it's already in there - any idea how to fix?

[flibitijibibo]

Your glibc/libstdc++ version is probably too new. For compatibility you'll probably want to build on something like Ubuntu 12.04, Mint 13 or Fedora 17. That or you can build on a current server that uses Debian or CentOS, those deliberately carry old glibc/libstdc++.

[vittorioromeo]

@flibitijibibo Apparently, even if I include libstdc++and set LD_LIBRARY_PATH, the game always tries to use the libstdc++ present on the user's system.

See: http://www.reddit.com/r/linuxquestions/comments/1gl4bg/distributing_game_binaries_on_linux_how/ http://www.reddit.com/r/linux4noobs/comments/1gl18i/distributing_game_binaries_on_linux_how/

Before compiling with an older version, is there a way to "override" the user's libstdc++ search path?

[vittorioromeo]

I've created a new test package, and people report it works.

Here's the used build-repository.sh:

#!/bin/bash

# This bash script, called in a repository with submodules, builds and installs all submodules then the project itself

export DESTDIR="~/Temp/SSVOpenHexagon/INSTALLTEST/"

PROJECTNAME=${PWD##*/} # Project to build (current directory name)
BUILDTYPE="RELEASE" # Passed to CMake (CMAKE_BUILD_TYPE)
BUILDSHARED="TRUE" # Passed to CMake (LIBNAME_BUILD_SHARED_LIB)

LIBS=() # List of extlibs to build (gathered from ./extlibs/*)
for dir in ./extlibs/*; do LIBS+=(${dir##*/}); done # Fill LIBS

# Builds a lib, with name $1 - calls CMake, make -j and make install -j
function buildLib 
{
    local LIBNAME="$1"
    local ULIBNAME=$(echo "$1" | tr '[:lower:]' '[:upper:]')

    echo "Building $ULIBNAME..." 
    cd $LIBNAME # Enter lib main directory (where CMakeLists.txt is)
    rm CMakeCache.txt # Remove CMakeCache.txt, in case an earlier (accidental) build was made in the main directory1
    mkdir build; cd build # Create and move to the build directory
    rm CMakeCache.txt # If the library was previously built, remove CMakeCache.txt

    # Run CMake, make and make install
    cmake ../ -D"$ULIBNAME"_BUILD_SHARED_LIB=$BUILDSHARED -DCMAKE_BUILD_TYPE=$BUILDTYPE -DCMAKE_SKIP_BUILD_RPATH=TRUE
    make -j; make install -j

    cd ../.. # Go back to extlibs directory
    echo "Finished building $ULIBNAME..."
}  

cd extlibs  # Start building... Enter extlibs, and build extlibs
for LIB in ${LIBS[*]}; do buildLib $LIB; done
cd .. # Now we are in the main folder
echo "Building $PROJECTNAME..." 
rm CMakeCache.txt # Remove CMakeCache.txt, in case an earlier (accidental) build was made in the main directory
mkdir build; cd build # Create and move to the build directory
rm CMakeCache.txt # If the library was previously built, remove CMakeCache.txt

## Run CMake, make and make install
cmake ../ -DCMAKE_BUILD_TYPE=$BUILDTYPE -DCMAKE_SKIP_BUILD_RPATH=TRUE
make -j; make install -j

cd ..
echo "Finished building $PROJECTNAME..."

Things to note are:

• -DCMAKE_SKIP_BUILD_RPATH=TRUE: this is the key! Not setting RPATH during build allows LD_LIBRARY_PATH to override default library search path, even for libraries like libstdc++.
• export DESTDIR="~/Temp/SSVOpenHexagon/INSTALLTEST/": overrides default installation directory, so that everything is installed using the DESTDIR path as a root. Very useful for quick distribution, as you don't have to pick the installed stuff from your file system.

[vittorioromeo]

Another useful command:

export CMAKE_PREFIX_PATH="~/Temp/SSVOpenHexagon/INSTALLTEST2/usr/local/"

Makes CMake find stuff in that path, not in the normal filesystem paths.