Portable Linux binaries? (64-bit only is OK)

SDL Development
1

Yes I know that the ideal thing would be to make packages for each
distro (even better, let the maintainers do it, but let’s say that
repos don’t work for commercial games :P), but I keep getting demands
for being able to just get a .tar.gz that you can decompress in a
directory you want (i.e. not packages), especially from those not
using Ubuntu. This means bundling the libraries to make sure it works,
and while it seems most work just fine, SDL2 causes it to crash when
run on a non-Ubuntu distro (and only that one, replacing SDL2 with the
distro one works even if the rest are left untouched).

So here’s the question: is there some sort of SDL2 build that’s
reasonably portable among Linux distros? I only care about x86-64 for
binary builds, in case somebody wonders (if you want 32-bit then just
rebuild from source >_>). Or should I just put a README and insist on
what libraries need to be installed?

PS: I’m using my own SDL2 build rather than the Ubuntu one, so maybe
that isn’t helping matters :stuck_out_tongue: But I know there are some fixes post
2.0.3 that are kind of important (e.g. IME support on Linux was only
added after 2.0.3.9008, I think?).

2

Yes I know that the ideal thing would be to make packages for each
distro (even better, let the maintainers do it, but let’s say that
repos don’t work for commercial games :P), but I keep getting demands
for being able to just get a .tar.gz that you can decompress in a
directory you want (i.e. not packages), especially from those not
using Ubuntu. This means bundling the libraries to make sure it works,
and while it seems most work just fine, SDL2 causes it to crash when
run on a non-Ubuntu distro (and only that one, replacing SDL2 with the
distro one works even if the rest are left untouched).

What kind of crash?

So here’s the question: is there some sort of SDL2 build that’s
reasonably portable among Linux distros? I only care about x86-64 for
binary builds, in case somebody wonders (if you want 32-bit then just
rebuild from source >_>). Or should I just put a README and insist on
what libraries need to be installed?

PS: I’m using my own SDL2 build rather than the Ubuntu one, so maybe
that isn’t helping matters :stuck_out_tongue: But I know there are some fixes post
2.0.3 that are kind of important (e.g. IME support on Linux was only
added after 2.0.3.9008, I think?).

Generally it might help to build it in a VM/chroot with a reasonably old
Linux distribution, maybe debian stable (wheezy) is enough, or oldstable
(squeeze) if you wanna be double-sure.

The “debootstrap” tool might help with that.
(For SDL itself an old distro causes no trouble, IIRC, but for other
code, especially C++11 code, it might be trickier because you might need
a newer compiler).

Anyway, I’d love to hear how Ryan builds the binaries of his ports, as
he has most experience with creating compatible binaries.

Cheers,
DanielOn 04/08/2015 11:50 PM, Sik the hedgehog wrote:

3

So here’s the question: is there some sort of SDL2 build that’s
reasonably portable among Linux distros? I only care about x86-64 for
binary builds, in case somebody wonders (if you want 32-bit then just
rebuild from source >_>). Or should I just put a README and insist on
what libraries need to be installed?

The libretro guys are compiling cores (emulators as shared objects) in a platform-independent way. You can find them at #libretro and check how they’re doing it.

Cheers,

Andre

4

2015-04-08 23:50 GMT+02:00 Sik the hedgehog <sik.the.hedgehog at gmail.com>:

Yes I know that the ideal thing would be to make packages for each
distro (even better, let the maintainers do it, but let’s say that
repos don’t work for commercial games :P), but I keep getting demands
for being able to just get a .tar.gz that you can decompress in a
directory you want (i.e. not packages), especially from those not
using Ubuntu. This means bundling the libraries to make sure it works,
and while it seems most work just fine, SDL2 causes it to crash when
run on a non-Ubuntu distro (and only that one, replacing SDL2 with the
distro one works even if the rest are left untouched).

So here’s the question: is there some sort of SDL2 build that’s
reasonably portable among Linux distros? I only care about x86-64 for
binary builds, in case somebody wonders (if you want 32-bit then just
rebuild from source >_>). Or should I just put a README and insist on
what libraries need to be installed?

PS: I’m using my own SDL2 build rather than the Ubuntu one, so maybe
that isn’t helping matters :stuck_out_tongue: But I know there are some fixes post
2.0.3 that are kind of important (e.g. IME support on Linux was only
added after 2.0.3.9008, I think?).

Hmm, it really shouldn’t crash. There’s nothing distro-specific inside SDL2
as far as I know. I build my bundled libs including SDL2 in a Ubuntu 12.04
VM and haven’t heard of anyone having problems running it on a different
distro yet.
You should really ask your users for a core dump to investigate this.

5

Could be that the users libc is older than his.

But he should really clarify what kind of crash he’s getting.

Cheers,
DanielOn 04/09/2015 01:26 AM, Jonas Kulla wrote:

Hmm, it really shouldn’t crash. There’s nothing distro-specific inside SDL2
as far as I know. I build my bundled libs including SDL2 in a Ubuntu 12.04
VM and haven’t heard of anyone having problems running it on a different
distro yet.
You should really ask your users for a core dump to investigate this.

6

2015-04-09 1:27 GMT+02:00 Daniel Gibson :> On 04/09/2015 01:26 AM, Jonas Kulla wrote:

Hmm, it really shouldn’t crash. There’s nothing distro-specific inside
SDL2
as far as I know. I build my bundled libs including SDL2 in a Ubuntu 12.04
VM and haven’t heard of anyone having problems running it on a different
distro yet.
You should really ask your users for a core dump to investigate this.

Could be that the users libc is older than his.

But he should really clarify what kind of crash he’s getting.

Cheers,
Daniel

Oh yeah you’re right, I normally don’t think of “failed to dynamically
link” as
"crashed" but that’s a very plausible scenario. Your bundled libs usually
only
work with either the same or a higher version of libc that you built with,
which is why most people build on their “minimum required Ubuntu version”,
me included.

7

Actually you would be surprised.
Unless you are making open source software which will be built and packaged
by the distro, never use the distro’s libraries/package manager.

If your application is shipped as binary and/or is close source all of its
dependencies should either be bundled or statically linked. This is even
recommended by the LSB.

You should build SDL in the same way as you build your binary and target a
specific version of glibc. You do this by either building against a runtime
such as the LSB or Steam Runtime or in a chroot such as mock or using
debootstrap or on a separate build machine with an much older glibc
version. You could also use a VM running an older linux distro.

If you use a runtime you have the added benefit that you do not need to
include all the library dependencies in your bundle but you also need to
make sure the user has that specific runtime available. There is also a
proposal for Gnome sandboxing that will create distro independent runtime
libraries. But there are a few issues with the Steam Runtime currently.

Mostly I would advise to build in a chroot and then bundle the libraries
dynamically linked with a relative rpath.

1 Like
8

2015-04-08 20:26 GMT-03:00, Jonas Kulla :

Hmm, it really shouldn’t crash. There’s nothing distro-specific inside SDL2
as far as I know.

The specific libraries it linked to could cause distro dependencies,
though (e.g. if there’s some naming convention difference, that alone
would cause a failure - note, no idea if this is the reason :P)

I build my bundled libs including SDL2 in a Ubuntu 12.04
VM and haven’t heard of anyone having problems running it on a different
distro yet.

Yeah but setting up a whole dedicated system just for building (a VM
is an entire computer being emulated, c’mon :P) seems like a mess,
especially given I only have a single computer :stuck_out_tongue: Although ugh, it
seems like the only reliable way outside of Windows builds.

And even then it may still build in a way that wouldn’t work outside
Ubuntu (e.g. mismatching filenames, depending on how each distro
handles them - dunno if there’s something like this that could
happen?)

You should really ask your users for a core dump to investigate this.

Eh, I’ll try to see what I can find, but yeah it seems to be an issue
getting SDL2 to link with the program when it tries to start (the
program ends up not booting as a result).

2015-04-08 20:27 GMT-03:00, Daniel Gibson :

Could be that the users libc is older than his.

We ruled this out already :confused: (it’s way higher than what the program
reports) Also this would probably cause problems with the other
libraries (which are also custom built since, um, I’m dumb >.>)

The one distro that I know for sure that causes issues is Arch, maybe
there’s something here? (assume fully updated Arch, these people don’t
stay with old versions) Especially since Ubuntu + Arch make up like
80% of Linux users.

9

J?rgen Tjerno wrote a couple blog posts on the subject:
http://jorgen.tjer.no/post/2014/05/26/self-contained-game-distribution-on-linux/ http://jorgen.tjer.no/post/2014/05/26/self-contained-game-distribution-on-linux/
http://jorgen.tjer.no/post/2014/05/28/steam-runtime-without-steam/ http://jorgen.tjer.no/post/2014/05/28/steam-runtime-without-steam/

10

I don’t know any specifics, but Arch also seems to have problems with
Steam Runtime (Arch users delete stuff from steam runtime so system libs
are used instead to fix those problems), maybe it’s related?
Does anyone know any details about that (why the old libs don’t work on
Arch)?

Cheers,
DanielOn 04/09/2015 04:21 AM, Sik the hedgehog wrote:

The one distro that I know for sure that causes issues is Arch, maybe
there’s something here? (assume fully updated Arch, these people don’t
stay with old versions) Especially since Ubuntu + Arch make up like
80% of Linux users.

11

The one distro that I know for sure that causes issues is Arch, maybe
there’s something here? (assume fully updated Arch, these people don’t
stay with old versions) Especially since Ubuntu + Arch make up like
80% of Linux users.

I don’t know any specifics, but Arch also seems to have problems with
Steam Runtime (Arch users delete stuff from steam runtime so system libs
are used instead to fix those problems), maybe it’s related?
Does anyone know any details about that (why the old libs don’t work on
Arch)?

I think this is mostly because the Steam Runtime ships its own libc but the
graphic libraries e.g. libGL will be built against a different version of
libc. You cannot dynamically load two different versions of the same
library so it would pick the Steam version and the libGL would fail to
load. Steam cannot ship libGL as that is graphics driver dependent.On Thu, Apr 9, 2015 at 11:24 AM, Daniel Gibson wrote:

On 04/09/2015 04:21 AM, Sik the hedgehog wrote:

12

I’ve got a bunch of scripts for building ultra-compatible builds of SDL:


I’ve shipped quite a few things with it. Most of the bingcc stuff isn’t
needed if you build on a system with old enough glibc, though.

I’ve also written a little bit on how to get proper binary compatibility
on Linux: https://davidgow.net/handmadepenguin/ch16.html It also has a
download for an ultra-compatible SDL2 build (I can’t remember which
version it actually has: it’d be the latest hg version from when I built it.

Hope that helps!
? DavidOn 08/04/15 19:24, Daniel Gibson wrote:

On 04/09/2015 04:21 AM, Sik the hedgehog wrote:

The one distro that I know for sure that causes issues is Arch, maybe
there’s something here? (assume fully updated Arch, these people don’t
stay with old versions) Especially since Ubuntu + Arch make up like
80% of Linux users.

I don’t know any specifics, but Arch also seems to have problems with
Steam Runtime (Arch users delete stuff from steam runtime so system libs
are used instead to fix those problems), maybe it’s related?
Does anyone know any details about that (why the old libs don’t work on
Arch)?

Cheers,
Daniel

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

13

Uhh, that’s painful… if steam doesn’t ship a libc, steam games will
fail on distros with an older libc, if it does, they will fail with
graphics drivers that expect a newer libc (probably only affects open
source drivers?)… what a mess.
They should have provided a really old libc for compiling and not
shipping any libc with steam runtime…
But at least we can learn from this that the only way is linking
against an old libc (or use a hack like suggested by David Glow, see
https://github.com/sulix/bingcc, to prevent depending on new symbols)

Cheers,
DanielOn 04/09/2015 04:27 AM, x414e54 wrote:

On Thu, Apr 9, 2015 at 11:24 AM, Daniel Gibson <@Daniel_Gibson

I don't know any specifics, but Arch also seems to have problems
with Steam Runtime (Arch users delete stuff from steam runtime so
system libs are used instead to fix those problems), maybe it's related?
Does anyone know any details about that (why the old libs don't work
on Arch)?

I think this is mostly because the Steam Runtime ships its own libc but
the graphic libraries e.g. libGL will be built against a different
version of libc. You cannot dynamically load two different versions of
the same library so it would pick the Steam version and the libGL would
fail to load. Steam cannot ship libGL as that is graphics driver dependent.

14

Yes I know that the ideal thing would be to make packages for each
distro

Nope, never do this.

(even better, let the maintainers do it,

Nope, never do this either*.

So here’s the question: is there some sort of SDL2 build that’s
reasonably portable among Linux distros? I only care about x86-64 for
binary builds, in case somebody wonders (if you want 32-bit then just
rebuild from source >_>). Or should I just put a README and insist on
what libraries need to be installed?

Copy the SDL2 out of the Steam Runtime. That’s what I do. It only links
against the C runtime and dlopen()s what it needs based on what’s
available on the end user’s system.

Install Steam, copy it out of
~/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0

(other goodies, like OpenAL, are good from there, too.)

You can also install the Steam Runtime SDK to get a compiler that
targets a reasonable glibc, etc, if you want that. But you can also just
cherry-pick the known-good SDL out of it. This works if you’re shipping
a .tar.gz, or a MojoSetup installer, etc, on Humble Bundle, GoG, whatever.

If you’re on Steam, don’t ship SDL with your game; let Steam provide it.

PS: I’m using my own SDL2 build rather than the Ubuntu one, so maybe
that isn’t helping matters :stuck_out_tongue: But I know there are some fixes post
2.0.3 that are kind of important (e.g. IME support on Linux was only
added after 2.0.3.9008, I think?).

The Steam Runtime build reports itself as 2.0.3 (hg-8628:b558f99d48f0),
but I could have sworn we’ve updated it since then. Maybe not.

–ryan.

*You can do this if your thing is open source and popular enough that
someone will do this for you without you being involved at all. If a
distro decides to package your work, that’s their burden and not yours,
and you shouldn’t expect this or rely on it. In short: when the system
works, it’s great, and it often doesn’t work…but in any case, it’s got
nothing to do with you.On 4/8/15 5:50 PM, Sik the hedgehog wrote:

15

Yeah but setting up a whole dedicated system just for building (a VM
is an entire computer being emulated, c’mon :P) seems like a mess,
especially given I only have a single computer :stuck_out_tongue: Although ugh, it
seems like the only reliable way outside of Windows builds.

I use a cross compiler; it runs like the usual GCC on my Linux box, but
it completely ignores any system-installed headers and libraries and
targets a different glibc, so it’s completely isolated from whatever I
happen to be building on.

I build this myself using crosstool-ng, but the Steam Runtime SDK comes
with a similar compiler for 32 and 64 bit targets that you can just drop
onto your Linux box and run (even if you aren’t shipping on Steam).

–ryan.

16

2015-04-09 4:21 GMT+02:00 Sik the hedgehog <sik.the.hedgehog at gmail.com>:

2015-04-08 20:26 GMT-03:00, Jonas Kulla <@Jonas_Kulla>:

I build my bundled libs including SDL2 in a Ubuntu 12.04
VM and haven’t heard of anyone having problems running it on a different
distro yet.

Yeah but setting up a whole dedicated system just for building (a VM
is an entire computer being emulated, c’mon :P) seems like a mess,
especially given I only have a single computer :stuck_out_tongue: Although ugh, it
seems like the only reliable way outside of Windows builds.

Is it inefficient? A bit, maybe. But it’s the opposite of a “mess”, because
everything is perfectly contained and I never have to worry at all about any
part of my work system contaminating the build. I’m not saying this is the
way
to got, just that this seems to always work for me (especially because my
working distro is not Ubuntu).
I also only have one PC, a 6 year old laptop.

And even then it may still build in a way that wouldn’t work outside
Ubuntu (e.g. mismatching filenames, depending on how each distro
handles them - dunno if there’s something like this that could
happen?)

What filenames are you thinking of? Again, SDL2 is completely
self-contained,
it doesn’t look at distro-specific things like where to find X11 libs and
hardcodes
that; almost everything is dynamically loaded with no regard to the build
environment.

17

Apart from that: even if you link against your systems libFoo, the
linker does not save "I want /usr/lib/x86_64-linux-gnu/libFoo.so.0"
into the executable, but “I want libFoo.so.0”, so if on another system
libFoo.so.0 lives in /usr/lib/ or /usr/lib64/ or whatever it doesn’t
matter, because the runtime linker loads it from wherever it can find it.
So paths don’t matter, but availability of the (right version) of a lib
does.

Cheers,
DanielOn 04/09/2015 04:28 PM, Jonas Kulla wrote:

2015-04-09 4:21 GMT+02:00 Sik the hedgehog <sik.the.hedgehog at gmail.com

And even then it may still build in a way that wouldn't work outside
Ubuntu (e.g. mismatching filenames, depending on how each distro
handles them - dunno if there's something like this that could
happen?)

What filenames are you thinking of? Again, SDL2 is completely
self-contained,
it doesn’t look at distro-specific things like where to find X11 libs
and hardcodes
that; almost everything is dynamically loaded with no regard to the build
environment.

18

What glibc version do you target or what do you think one should target?

Newer versions sometimes have:

so not targeting (for example) 2.3 but something newer may have its
benefits, but you gotta draw the line somewhere to be compatible with
older distros - where?

Cheers,
DanielOn 04/09/2015 08:08 AM, Ryan C. Gordon wrote:

Yeah but setting up a whole dedicated system just for building (a VM
is an entire computer being emulated, c’mon :P) seems like a mess,
especially given I only have a single computer :stuck_out_tongue: Although ugh, it
seems like the only reliable way outside of Windows builds.

I use a cross compiler; it runs like the usual GCC on my Linux box, but
it completely ignores any system-installed headers and libraries and
targets a different glibc, so it’s completely isolated from whatever I
happen to be building on.

I build this myself using crosstool-ng, but the Steam Runtime SDK comes
with a similar compiler for 32 and 64 bit targets that you can just drop
onto your Linux box and run (even if you aren’t shipping on Steam).

–ryan.

19

Am I seriously the only one who thinks that having to set up a whole
system (c’mon, that’s what a VM is :P) with an ancient distro just to
be able to build executables that will run on different also
up-to-date distros (not even older ones) is ridiculous? :confused:

Anyway, trying bingcc again to see if that works. I don’t remember
what was the problem with it before. I think it didn’t look like it
had done its job as intended? But I’ll make more tests this time to
make 100% sure, maybe it was just misleading information.

20

OK building with bingcc failed… in a rather specific way (in the
linker stage):

LTLINK build/libSDL2.la
build/.libs/SDL_ibus.o: In function SDL_IBus_Quit': /home/sik/Descargas/SDL-2.0.4-9174/src/core/linux/SDL_ibus.c:509: undefined reference toinotify_rm_watch at GLIBC_NOT_AVAILABLE_BEFORE_2.4’
build/.libs/SDL_ibus.o: In function SDL_IBus_Init': /home/sik/Descargas/SDL-2.0.4-9174/src/core/linux/SDL_ibus.c:476: undefined reference toinotify_add_watch at GLIBC_NOT_AVAILABLE_BEFORE_2.4’
/home/sik/Descargas/SDL-2.0.4-9174/src/core/linux/SDL_ibus.c:467:
undefined reference to inotify_init at GLIBC_NOT_AVAILABLE_BEFORE_2.4' /usr/bin/ld: build/.libs/libSDL2-2.0.so.0.4.0: No symbol version section for versioned symbolinotify_rm_watch at GLIBC_NOT_AVAILABLE_BEFORE_2.4’
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: *** [build/libSDL2.la] Error 1

It looks like all the problems are related to iBus? Also, remember how
I said that 2.0.3 didn’t have IME support on Linux, and that one of
the reasons for providing my own SDL2 was so it included that support?
Now I’m wondering if it was the IME support what was breaking it all
along. (this would also make sense given how before we had ruled out
glibc being the issue with Arch)