Portable Linux binaries? (64-bit only is OK) |
Sik
|
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 ), 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 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?). _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Daniel Gibson
Guest
|
On 04/08/2015 11:50 PM, Sik the hedgehog wrote:
What kind of crash?
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 _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
andre
Guest
|
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 _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Portable Linux binaries? (64-bit only is OK) |
Daniel Gibson
Guest
|
On 04/09/2015 01:26 AM, Jonas Kulla wrote:
Could be that the users libc is older than his. But he should really clarify what kind of crash he's getting. Cheers, Daniel _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Jonas Kulla
Guest
|
2015-04-09 1:27 GMT+02:00 Daniel Gibson:
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. |
|||||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
x414e54
|
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. |
|||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Sik
|
2015-04-08 20:26 GMT-03:00, Jonas Kulla:
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 )
Yeah but setting up a whole dedicated system just for building (a VM is an entire computer being emulated, c'mon ) seems like a mess, especially given I only have a single computer 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?)
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:
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. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Alex Szpakowski
Guest
|
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/28/steam-runtime-without-steam/ |
|||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Daniel Gibson
Guest
|
On 04/09/2015 04:21 AM, Sik the hedgehog wrote:
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 |
|||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
x414e54
|
On Thu, Apr 9, 2015 at 11:24 AM, Daniel Gibson wrote:
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. |
|||||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
David Gow
Guest
|
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 On 08/04/15 19:24, Daniel Gibson wrote:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Daniel Gibson
Guest
|
On 04/09/2015 04:27 AM, x414e54 wrote:
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 _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Ryan C. Gordon
Guest
|
On 4/8/15 5:50 PM, Sik the hedgehog wrote:
Nope, never do this.
Nope, never do this either*.
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.
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. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Ryan C. Gordon
Guest
|
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. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Jonas Kulla
Guest
|
2015-04-09 4:21 GMT+02:00 Sik the hedgehog:
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. Â
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. |
|||||||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Daniel Gibson
Guest
|
On 04/09/2015 04:28 PM, Jonas Kulla wrote:
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 _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Daniel Gibson
Guest
|
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 On 04/09/2015 08:08 AM, Ryan C. Gordon wrote:
_______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Sik
|
Am I seriously the only one who thinks that having to set up a whole
system (c'mon, that's what a VM is ) 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. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Sik
|
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 `' 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 `' /home/sik/Descargas/SDL-2.0.4-9174/src/core/linux/SDL_ibus.c:467: 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 |
|||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Alex Baines
Guest
|
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). On 09/04/15 22:08, Sik the hedgehog wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
David Gow
Guest
|
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 On Apr 9, 2015 2:25 PM, "Alex Baines" wrote:
|
|||||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Sik
|
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. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Sik
|
2015-04-09 18:40 GMT-03:00, Sik the hedgehog:
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. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Sik
|
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) _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Alex Baines
Guest
|
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. On 10/04/15 01:57, Sik the hedgehog wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Sik
|
2015-04-10 8:32 GMT-03:00, Alex Baines:
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 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 _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Sik
|
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. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Ryan C. Gordon
Guest
|
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. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Ryan C. Gordon
Guest
|
(...or maybe it _does_ fix it. ) --ryan. _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
Portable Linux binaries? (64-bit only is OK) |
Eric Wing
Guest
|
On 4/13/15, Ryan C. Gordon wrote:
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/ _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|