The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.


SDL Forum Index
SDL
Simple Directmedia Layer Forums
Portable Linux binaries? (64-bit only is OK)
Sik


Joined: 26 Nov 2011
Posts: 905
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 Razz), 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 Razz 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:
Quote:
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 Razz), 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?

Quote:

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 Razz 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
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Portable Linux binaries? (64-bit only is OK)
andre
Guest

Quote:
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


_______________________________________________
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-08 23:50 GMT+02:00 Sik the hedgehog:
Quote:
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 Razz), 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 Razz 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.
Portable Linux binaries? (64-bit only is OK)
Daniel Gibson
Guest

On 04/09/2015 01:26 AM, Jonas Kulla wrote:
Quote:

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
_______________________________________________
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:
Quote:
On 04/09/2015 01:26 AM, Jonas Kulla wrote:
Quote:

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.
Portable Linux binaries? (64-bit only is OK)
x414e54


Joined: 19 Mar 2015
Posts: 8
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


Joined: 26 Nov 2011
Posts: 905
2015-04-08 20:26 GMT-03:00, Jonas Kulla:
Quote:
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 Razz)

Quote:
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 Razz) seems like a mess,
especially given I only have a single computer Razz 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?)

Quote:
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:
Quote:
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.
_______________________________________________
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:
Quote:
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
Portable Linux binaries? (64-bit only is OK)
x414e54


Joined: 19 Mar 2015
Posts: 8
On Thu, Apr 9, 2015 at 11:24 AM, Daniel Gibson wrote:
Quote:
On 04/09/2015 04:21 AM, Sik the hedgehog wrote:
Quote:
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. 
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:
Quote:
On 04/09/2015 04:21 AM, Sik the hedgehog wrote:
Quote:
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

_______________________________________________
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:
Quote:

On Thu, Apr 9, 2015 at 11:24 AM, 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

_______________________________________________
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:
Quote:
Yes I know that the ideal thing would be to make packages for each
distro

Nope, never do this.

Quote:
(even better, let the maintainers do it,

Nope, never do this either*.

Quote:
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.

Quote:
PS: I'm using my own SDL2 build rather than the Ubuntu one, so maybe
that isn't helping matters Razz 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.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Portable Linux binaries? (64-bit only is OK)
Ryan C. Gordon
Guest

Quote:
Yeah but setting up a whole dedicated system just for building (a VM
is an entire computer being emulated, c'mon Razz) seems like a mess,
especially given I only have a single computer Razz 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.


_______________________________________________
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:
Quote:
2015-04-08 20:26 GMT-03:00, Jonas Kulla:
Quote:
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 Razz) seems like a mess,
especially given I only have a single computer Razz 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.

 

Quote:
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.
Portable Linux binaries? (64-bit only is OK)
Daniel Gibson
Guest

On 04/09/2015 04:28 PM, Jonas Kulla wrote:
Quote:
2015-04-09 4:21 GMT+02:00 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
_______________________________________________
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:
Quote:

Quote:
Yeah but setting up a whole dedicated system just for building (a VM
is an entire computer being emulated, c'mon Razz) seems like a mess,
especially given I only have a single computer Razz 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.


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Portable Linux binaries? (64-bit only is OK)
Sik


Joined: 26 Nov 2011
Posts: 905
Am I seriously the only one who thinks that having to set up a whole
system (c'mon, that's what a VM is Razz) 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


Joined: 26 Nov 2011
Posts: 905
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:
Quote:
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

_______________________________________________
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:
Quote:
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:
Quote:
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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Portable Linux binaries? (64-bit only is OK)
Sik


Joined: 26 Nov 2011
Posts: 905
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


Joined: 26 Nov 2011
Posts: 905
2015-04-09 18:40 GMT-03:00, Sik the hedgehog:
Quote:
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.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Portable Linux binaries? (64-bit only is OK)
Sik


Joined: 26 Nov 2011
Posts: 905
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:
Quote:
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

_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Portable Linux binaries? (64-bit only is OK)
Sik


Joined: 26 Nov 2011
Posts: 905
2015-04-10 8:32 GMT-03:00, Alex Baines:
Quote:
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.

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 Razz 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 Razz
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Portable Linux binaries? (64-bit only is OK)
Sik


Joined: 26 Nov 2011
Posts: 905
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

Quote:
Doesn't work! >_< And it does seem to be specifically an iBus issue:
"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.






_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Portable Linux binaries? (64-bit only is OK)
Ryan C. Gordon
Guest

Quote:
THAT WAS IT \o\ /o/ \o/ *offers cake to everybody*

(...or maybe it _does_ fix it. Smile )

--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:
Quote:

Quote:
THAT WAS IT \o\ /o/ \o/ *offers cake to everybody*

(...or maybe it _does_ fix it. Smile )

--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/
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org