Discussion:
Portable Linux binaries? (64-bit only is OK)
(too old to reply)
Sik the hedgehog
2015-04-08 21:50:59 UTC
Permalink
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 :P 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?).
Daniel Gibson
2015-04-08 22:09:15 UTC
Permalink
Post by Sik the hedgehog
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?
Post by Sik the hedgehog
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 :P 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,
Daniel
a***@leiradella.com
2015-04-08 22:27:28 UTC
Permalink
Post by Sik the hedgehog
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
Jonas Kulla
2015-04-08 23:26:10 UTC
Permalink
Post by Sik the hedgehog
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 :P 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.
Daniel Gibson
2015-04-08 23:27:36 UTC
Permalink
Post by Jonas Kulla
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
Jonas Kulla
2015-04-08 23:32:42 UTC
Permalink
Post by Daniel Gibson
Post by Jonas Kulla
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.
x414e54
2015-04-09 02:20:39 UTC
Permalink
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.
Alex Szpakowski
2015-04-09 02:23:40 UTC
Permalink
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/>
Sik the hedgehog
2015-04-09 02:21:56 UTC
Permalink
Post by 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)
Post by 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 :P 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?)
Post by Jonas Kulla
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).
Post by Jonas Kulla
Could be that the users libc is older than his.
We ruled this out already :/ (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.
Daniel Gibson
2015-04-09 02:24:44 UTC
Permalink
Post by Sik the hedgehog
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
x414e54
2015-04-09 02:27:23 UTC
Permalink
Post by Daniel Gibson
Post by Sik the hedgehog
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.
Daniel Gibson
2015-04-09 02:35:11 UTC
Permalink
Post by 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.
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,
Daniel
David Gow
2015-04-09 02:31:09 UTC
Permalink
I've got a bunch of scripts for building ultra-compatible builds of SDL:
https://github.com/sulix/bingcc/tree/master/examples
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!
— David
Post by Daniel Gibson
Post by Sik the hedgehog
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
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Ryan C. Gordon
2015-04-09 06:08:55 UTC
Permalink
Post by Sik the hedgehog
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 :P 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.
Daniel Gibson
2015-04-09 15:52:41 UTC
Permalink
What glibc version do you target or what do you think one should target?

Newer versions sometimes have:
* faster implementation of things
* more correct implementation of things (e.g.
https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/
does not happen in newer versions of glibc that don't use x86 fsin)
* new functions one might want to use (like pthread_setname_np)..

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,
Daniel
Post by Ryan C. Gordon
Post by Sik the hedgehog
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 :P 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.
Sik the hedgehog
2015-04-09 21:00:33 UTC
Permalink
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? :/

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.
Sik the hedgehog
2015-04-09 21:08:51 UTC
Permalink
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 to
`***@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 to
`***@GLIBC_NOT_AVAILABLE_BEFORE_2.4'
/home/sik/Descargas/SDL-2.0.4-9174/src/core/linux/SDL_ibus.c:467:
undefined reference to `***@GLIBC_NOT_AVAILABLE_BEFORE_2.4'
/usr/bin/ld: build/.libs/libSDL2-2.0.so.0.4.0: No symbol version
section for versioned symbol
`***@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)
Alex Baines
2015-04-09 21:25:35 UTC
Permalink
The current IBus stuff requires those inotify functions from GLIBC2_4.
I'm guessing the bingcc method of building has a lower available version.

If you still want IBus without GLIBC_2.4 you can probably just comment
out the inotify related lines given in the error message. It should
work, but only if IBus is started before the SDL program (which it most
likely is anyway).
Post by Sik the hedgehog
OK building with bingcc failed... in a rather specific way (in the
LTLINK build/libSDL2.la
undefined reference to
undefined reference to
/usr/bin/ld: build/.libs/libSDL2-2.0.so.0.4.0: No symbol version
section for versioned symbol
/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)
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
David Gow
2015-04-09 21:30:25 UTC
Permalink
You can reconfigure bingcc to use a newer glibc with the setup-bingcc
script: the inotify stuff seems to need a newer version, so try posting a
newer glibc version. Given that Steam needs glibc 2.15, you're usually safe
with anything <= that.

— David
Post by Alex Baines
The current IBus stuff requires those inotify functions from GLIBC2_4.
I'm guessing the bingcc method of building has a lower available version.
If you still want IBus without GLIBC_2.4 you can probably just comment
out the inotify related lines given in the error message. It should
work, but only if IBus is started before the SDL program (which it most
likely is anyway).
Post by Sik the hedgehog
OK building with bingcc failed... in a rather specific way (in the
LTLINK build/libSDL2.la
undefined reference to
undefined reference to
/usr/bin/ld: build/.libs/libSDL2-2.0.so.0.4.0: No symbol version
section for versioned symbol
/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)
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Sik the hedgehog
2015-04-09 21:40:57 UTC
Permalink
OK so here's the deal:

2.0.4-9174: doesn't build
2.0.3 (vanilla): builds and works on the problematic system just fine

So yeah it seems like the problem may be iBus. I'll now go run
setup-bingcc and see if that lets me keep iBus while still working.
Sik the hedgehog
2015-04-09 21:57:29 UTC
Permalink
Post by Sik the hedgehog
So yeah it seems like the problem may be iBus. I'll now go run
setup-bingcc and see if that lets me keep iBus while still working.
Doesn't work! >_< And it does seem to be specifically an iBus issue:
"arguments to dbus_connection_open_private() were incorrect"

Looks like the problem is whatever that inotify thing does... I'll try
later removing it and see if that works.
Sik the hedgehog
2015-04-10 00:57:05 UTC
Permalink
OK the conclusions so far are:

1) Having iBus support (needed for IME on Linux) breaks SDL2 on Arch,
throwing out an error related to dBus initialization.

2) Removing those lines that bingcc was complaining about (and
replacing them with fail values) doesn't help make it go away at all,
so the problem must be something that the iBus code is doing in
general rather than a glibc issue. In fact I'm not even sure bingcc is
really needed here.

3) Either the Arch builds don't include the IME support or they are
modified to somehow do something else.

Does anybody have any idea what could this be? Is there enough
information to get this on Bugzilla? (right after the final bugfixing
list has been made... yay)
Alex Baines
2015-04-10 11:32:58 UTC
Permalink
There was an entry on bugzilla about a dbus error message that was
recently fixed related to passing NULL to dbus_connection_open_private:
https://bugzilla.libsdl.org/show_bug.cgi?id=2862

If that is the same error message you were getting, then check to see if
your build of SDL has the fix committed or not.

If it's a different error message then that sounds like something that
should be fixed before 2.0.4. It would be helpful to see the exact
message so I can look into it.
Post by Sik the hedgehog
1) Having iBus support (needed for IME on Linux) breaks SDL2 on Arch,
throwing out an error related to dBus initialization.
2) Removing those lines that bingcc was complaining about (and
replacing them with fail values) doesn't help make it go away at all,
so the problem must be something that the iBus code is doing in
general rather than a glibc issue. In fact I'm not even sure bingcc is
really needed here.
3) Either the Arch builds don't include the IME support or they are
modified to somehow do something else.
Does anybody have any idea what could this be? Is there enough
information to get this on Bugzilla? (right after the final bugfixing
list has been made... yay)
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Sik the hedgehog
2015-04-10 17:25:11 UTC
Permalink
Post by Alex Baines
There was an entry on bugzilla about a dbus error message that was
https://bugzilla.libsdl.org/show_bug.cgi?id=2862
If that is the same error message you were getting, then check to see if
your build of SDL has the fix committed or not.
If it's a different error message then that sounds like something that
should be fixed before 2.0.4. It would be helpful to see the exact
message so I can look into it.
THAT WAS IT \o\ /o/ \o/ *offers cake to everybody*

Now it works even when not using bingcc (I'll probably keep using
bingcc later anyway to be safer). Nice :P I wonder why the person who
reported it just got the message while my game would outright stop,
though. Oh well, doesn't matter now :P
Sik the hedgehog
2015-04-11 01:14:56 UTC
Permalink
OK it seems that after more testing nobody so far has problems after
that change (except somebody with joystick problems but that isn't
SDL2 since the test programs work just fine) so I guess the case is
closed. Thanks for all the help!

If anybody else is having problems distributing recent SDL2 binaries
to some people using Linux (especially not Ubuntu-based distros), take
a look into that patch.
Ryan C. Gordon
2015-04-14 01:48:29 UTC
Permalink
Post by Sik the hedgehog
THAT WAS IT \o\ /o/ \o/ *offers cake to everybody*
(...or maybe it _does_ fix it. :) )

--ryan.
Eric Wing
2015-04-21 09:19:28 UTC
Permalink
Post by Ryan C. Gordon
Post by Sik the hedgehog
THAT WAS IT \o\ /o/ \o/ *offers cake to everybody*
(...or maybe it _does_ fix it. :) )
--ryan.
Yes, my dbus message went away using a pull from a few days ago. I had
a user report the dbus thing led to an application crash on their
Fedora system. I'm waiting to hear back if this fixes it for them.

Thanks,
Eric
--
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
Ryan C. Gordon
2015-04-14 01:43:52 UTC
Permalink
Post by Sik the hedgehog
"arguments to dbus_connection_open_private() were incorrect"
This specific error goes away in this revision (applied a few days ago)...

https://hg.libsdl.org/SDL/rev/0288195afd8c

...but doesn't necessarily fix the problem you're having, I think.

--ryan.
Jonas Kulla
2015-04-09 14:28:10 UTC
Permalink
Post by Sik the hedgehog
Post by 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 :P 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.
Post by Sik the hedgehog
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.
Daniel Gibson
2015-04-09 14:35:34 UTC
Permalink
Post by Sik the hedgehog
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.
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,
Daniel
Ryan C. Gordon
2015-04-09 05:07:42 UTC
Permalink
Post by Sik the hedgehog
Yes I know that the ideal thing would be to make packages for each
distro
Nope, never do this.
Post by Sik the hedgehog
(even better, let the maintainers do it,
Nope, never do this either*.
Post by Sik the hedgehog
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.
Post by Sik the hedgehog
PS: I'm using my own SDL2 build rather than the Ubuntu one, so maybe
that isn't helping matters :P 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.
Continue reading on narkive:
Loading...