Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: distributing SFML projects on Linux (binaries)  (Read 13629 times)

0 Members and 1 Guest are viewing this topic.

zmertens

  • Jr. Member
  • **
  • Posts: 80
    • View Profile
distributing SFML projects on Linux (binaries)
« on: February 07, 2015, 06:43:03 am »
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.
The truth will set you free but first it will piss you off.

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: distributing SFML projects on Linux (binaries)
« Reply #1 on: February 07, 2015, 10:58:52 am »
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

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: distributing SFML projects on Linux (binaries)
« Reply #2 on: February 07, 2015, 04:46:09 pm »
« Last Edit: February 07, 2015, 04:52:20 pm by Jesper Juhl »

MorleyDev

  • Full Member
  • ***
  • Posts: 219
  • "It is not enough for code to work."
    • View Profile
    • http://www.morleydev.co.uk/
Re: distributing SFML projects on Linux (binaries)
« Reply #3 on: February 07, 2015, 05:26:10 pm »
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
« Last Edit: February 08, 2015, 04:37:57 am by MorleyDev »
UnitTest11 - A unit testing library in C++ written to take advantage of C++11.

All code is guilty until proven innocent, unworthy until tested, and pointless without singular and well-defined purpose.

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: distributing SFML projects on Linux (binaries)
« Reply #4 on: February 07, 2015, 10:33:51 pm »
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

  • Full Member
  • ***
  • Posts: 120
  • Experienced Programmer
    • View Profile
    • Simon-Burchert.com
Re: distributing SFML projects on Linux (binaries)
« Reply #5 on: February 13, 2015, 02:47:57 pm »
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?
Please note that my previous display name was "Shy Guy".

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: distributing SFML projects on Linux (binaries)
« Reply #6 on: February 13, 2015, 03:00:28 pm »
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.
« Last Edit: February 13, 2015, 03:05:16 pm by Jesper Juhl »

Tenry

  • Full Member
  • ***
  • Posts: 120
  • Experienced Programmer
    • View Profile
    • Simon-Burchert.com
Re: distributing SFML projects on Linux (binaries)
« Reply #7 on: February 13, 2015, 03:38:27 pm »
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).
Please note that my previous display name was "Shy Guy".

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: distributing SFML projects on Linux (binaries)
« Reply #8 on: February 13, 2015, 03:49:20 pm »
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.
« Last Edit: February 13, 2015, 03:53:34 pm by Jesper Juhl »

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email

Tenry

  • Full Member
  • ***
  • Posts: 120
  • Experienced Programmer
    • View Profile
    • Simon-Burchert.com
Re: distributing SFML projects on Linux (binaries)
« Reply #10 on: February 13, 2015, 03:57:25 pm »
Please note that my previous display name was "Shy Guy".

MorleyDev

  • Full Member
  • ***
  • Posts: 219
  • "It is not enough for code to work."
    • View Profile
    • http://www.morleydev.co.uk/
Re: distributing SFML projects on Linux (binaries)
« Reply #11 on: February 13, 2015, 08:19:13 pm »
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
UnitTest11 - A unit testing library in C++ written to take advantage of C++11.

All code is guilty until proven innocent, unworthy until tested, and pointless without singular and well-defined purpose.

Tenry

  • Full Member
  • ***
  • Posts: 120
  • Experienced Programmer
    • View Profile
    • Simon-Burchert.com
Re: distributing SFML projects on Linux (binaries)
« Reply #12 on: February 14, 2015, 10:52:49 am »
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.
Please note that my previous display name was "Shy Guy".

zmertens

  • Jr. Member
  • **
  • Posts: 80
    • View Profile
Re: distributing SFML projects on Linux (binaries)
« Reply #13 on: February 14, 2015, 11:24:09 pm »
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.
The truth will set you free but first it will piss you off.

Tenry

  • Full Member
  • ***
  • Posts: 120
  • Experienced Programmer
    • View Profile
    • Simon-Burchert.com
Re: distributing SFML projects on Linux (binaries)
« Reply #14 on: February 15, 2015, 01:41:47 am »
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.
Please note that my previous display name was "Shy Guy".