distributing SFML projects on Linux (binaries)

[zmertens]

I just started really using Linux (Ubuntu) a couple months ago and I was wondering how you guys distribute a binary on Linux (so excluding CMake or source files which I realize is the preferred Linux way). The context for this situation is if I just wanted somebody to be able to play my game right away (like on itch.io). Could I just have the SFML .so files adjacent to the binary similar to .dlls on Windows? I looked at static linking but I saw some posts on Stack Overflow which suggested this might be a bad thing to do.

Anyone comments or tips would be awesome.

[Mario]

You could put the library files next to your binary but they won't be used unless you set LD_LIBRARY_PATH.

So you could write a small shell script to launch your game or create your own bootstrap executable not requiring any other dependencies, which will set LD_LIBRARY_PATH to the current directory and then start the actual game.

[Jesper Juhl]

You can do it a lot simpler than that by using the linkers -rpath option and $ORIGIN to set the path to the libraries to be relative to the location of the  executable.

Read these links:

https://enchildfone.wordpress.com/2010/03/23/a-description-of-rpath-origin-ld_library_path-and-portable-linux-binaries/

https://www.technovelty.org/linux/exploring-origin.html

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

http://man7.org/linux/man-pages/man8/ld.so.8.html

[MorleyDev]

Not sure how good a practice this is, probably a terrible one, but at the moment when I'm doing C++ stuff then as a part of my build process, I have CMake copy some launch scripts to the root install directory. The launch script for linux looks something like this:

Code: [Select]

#!/bin/sh

LD_LIBRARY_PATH=$(dirname "$(readlink -f "$0")")/lib exec $(dirname "$(readlink -f "$0")")/bin/engine

Basically it adds the lib folder to the LD_LIBRARY_PATH (and works regardless of where the script is ran from) and then runs the engine executable in the bin folder.

You can actually kinda fake this behaviour for windows too if needed. The equivalent script on windows looks like:

Code: [Select]

@echo off
setlocal
PATH=%PATH%;%~dp0\lib
"%~dp0\bin\engine.exe"
endlocal


[Mario]

For Windows you don't need to do that. the executable's own path is always the first lookup location (even before other entries in the PATH environment variable; and considering that dynamic libraries should be in the bin path, not some lib dir).

[Tenry]

Some linux distros already provide SFML in the official repositories (such as Linux Mint 17.1, having SFML 2.1), so I would like to distribute my binary with its game data in an archive (e.g. tar.gz) and tell the user he has to install SFML 2.1 via package manager. Unfortunately, some distros don't have SFML or only version 1.6 in the official repository. So, I should rather provide the SFML binaries with the archive? I'm not sure, if that is the best design (of not working with system dependent packages like rpm or deb). Any ideas?

[Jesper Juhl]

Personally I would do the following if I wanted to distribute as a .tar.gz :

Package my application so that when you extract app.tar.gz you'd get an "app/" directory with 3 subdirectories; "lib/", "bin/" and "data/".
My applications binary(s) would go in "app/bin/", SFML and other libraries my app depends on would go in "app/lib/" and other stuff like music files, graphics etc would go in "app/data/". If I had configuration files I'd probably put them in a "app/etc/" directory.

When building my app I would make sure to set my apps path to the libraries it needs to be relative to the location of the executable, using the -rpath option for the linker along with $ORIGIN, so that my app would look for its libraries in "../lib/" independently of where it is located.

This way, when the user extracts the tarball they can put the toplevel "app/" directory wherever they please. Locations like "/opt/app/", "/usr/local/app/" and "~/app/" will all work equally well - as will symlinks to the executables that the user may choose to create.

At runtime when the app needs to find its own files in "data/" & "etc/" it can just read the  "/proc/self/exe" symlink to find out where it is located, strip the executable name from that path and add "../data/" and it then has a path to its data files. This works regardless of where the user moves the app to.

[Tenry]

At runtime when the app needs to find its own files in "data/" & "etc/" it can just read the  "/proc/self/exe" symlink to find out where it is located, strip the executable name from that path and add "../data/" and it then has a path to its data files. This works regardless of where the user moves the app to.

Wouldn't it work using the path passed with the first argument to main (argv[0]) as well?

There should be tutorials on the wiki about best practices distributing SFML apps for Windows, Linux and Mac (at least, I can't see any such tutorial yet).

[Jesper Juhl]

Using argv[0] is not reliable. It could be set to anything by a program launching your app. The fact that it is often set to the path to (or just name of) your executable is purely a convention and if you have symlinks or hardlinks in play that will also mess you up.
On the other hand, /proc/self/exe is reliable.

[Jesper Juhl]

This link may also be of some use/interest: http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

[Tenry]

This link may also be of some use/interest: http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

That's interesting and useful, thanks!

[MorleyDev]

If you're using CMake as a build system, there is also support for configuring your projects like Jesper suggests via setting the RPATH: http://www.cmake.org/Wiki/CMake_RPATH_handling

[Tenry]

Hm, if you suggest to distribute the SFML lib (.so) with the app anyway, why not linking the app statically with SFML then? That would even eliminate code, that is never called by the app.

[zmertens]

Hm, if you suggest to distribute the SFML lib (.so) with the app anyway, why not linking the app statically with SFML then? That would even eliminate code, that is never called by the app.

I was reading around the Web and I thought I came across some discussions that static linking on Linux wasn't preferred (although I can't remember the exact reasons - I think it was a StackOverflow discussion). I was hoping to get a second opinion and to see how long time Linux / SFML users would consider distributing their applications. I've been browsing Itch.io a lot recently and I want to distribute my project there. It seems that a lot of the projects uploaded there which support Linux use Unity which I think takes care of linking automatically  but I just was looking for a second opinion.

Also, thanks for all the excellent feedback and links, its been very helpful and educational.

[Tenry]

I was reading around the Web and I thought I came across some discussions that static linking on Linux wasn't preferred (although I can't remember the exact reasons - I think it was a StackOverflow discussion).

As far, as I know, dynamic linking is preffered on Linux because it usually has a well managed package manager. For example, don't link your Linux app statically with OpenAL or FreeType, use the dynamic linking and let the package manager care about the dependencies. And, unlike Windows, on Linux having several versions of the same library for dynamic linking is quite good supported. However, what about less known/distributed libraries? I don't know.