Fedora as compo Linux distribution?
category: general [glöplog]
Quote:
For audio, this probably matters even less, because if you want to use a 'classical' 4k synth (like 4klang or clinkster or oidos), you'll have to include a 32-bit "sub-executables" as those synths only have 32-bit runtimes anyway.
Summoning some awful hackiness lets you avoid a sub-executable though, so SDL_Audio would be useful, but it's not crucial.
I use arch.
Quote:
As for saying that using SDL is a "hack abusing other installed-by-default's programs", well, several recent intros have used libopus, ghostscript/libspectre, librsvg, libfftw, cogl and clutter, Python, and so on. I don't quite find this "cheating", I find it an interesting new space to explore as for what can be done with Linux intros. Windows has gm.dls anyway, so why can't we have something fun?
I'm not saying it's cheating. I'm saying it's fragile. I want my prods to work in 10 years as well as during the compo.
It's a bit like the import by ordinal mess that we stopped doing on windows because it broke every major windows update.
@kusma: The longevity of intros is definitely something to consider.
However, i think gtk is developing much quicker than SDL, so i don't see the fragility argument.
Unless you mean the availability as a default package
in Fedora, i agree that this is fragile.
The way gtk is used in intros is much more likely to break in
future releases of gtk than for SDL, in my opinion.
However, i think gtk is developing much quicker than SDL, so i don't see the fragility argument.
Unless you mean the availability as a default package
in Fedora, i agree that this is fragile.
The way gtk is used in intros is much more likely to break in
future releases of gtk than for SDL, in my opinion.
That SDL forwards compatibility argument is also news to me. Have there been instances where a program written for SDL x.y didn't work with SDL x.z, with z > y?
I mean, sure, SDL itself is sometimes (very) buggy, but in my experience, this rather improves over time instead of regressing, so color me surprised. (The exception is the SDL1->2 switch, which broke all kinds of things, but even that is slowly settling now.)
I mean, sure, SDL itself is sometimes (very) buggy, but in my experience, this rather improves over time instead of regressing, so color me surprised. (The exception is the SDL1->2 switch, which broke all kinds of things, but even that is slowly settling now.)
I think you're getting confused here, maybe I wasn't clear enough.
My argument that depending on libraries that are installed as residue due to other system components is a hack, is what I'm saying is a compatibility issue waiting to happen.
I'm not arguing that using SDL specifically is a compatibility problem. If anything, SDL will increase compatibility, as long as you're ensured that it exists on the system you're targeting, because SDL gets actively maintained.
I'm really making two separate arguments here:
I hope that makes things a bit clearer.
GTK provides backwards compatibility, and is as close to what you can call a system component in virtually every distribution. There's no compatibility problem using GTK like you suggest. Moving fast isn't a problem as long as they don't break things.
All that above being said, I have seen intros fail to link because they've linked too specifically; e.g linked to a too specific soname, causing issues on distros that have moved to a newer SDL version that doesn't match any more.
But that's a fairly minor issue, and probably not intentional. And it's easy to work around with a local symlink and LD_LIBRARY_PATH.
My argument that depending on libraries that are installed as residue due to other system components is a hack, is what I'm saying is a compatibility issue waiting to happen.
I'm not arguing that using SDL specifically is a compatibility problem. If anything, SDL will increase compatibility, as long as you're ensured that it exists on the system you're targeting, because SDL gets actively maintained.
I'm really making two separate arguments here:
- I don't think SDL should be considered a system component. That's an argument targeted at the original topic of this thread, which is more about compo rules than development methodology.
- I don't think it's a good idea to link to libraries just because they are there on the system you're working at. This argument is targeted at developers. This is the argument that porocyon replied to, but it's really a side-discussion in this thread.
I hope that makes things a bit clearer.
Quote:
However, i think gtk is developing much quicker than SDL, so i don't see the fragility argument.
GTK provides backwards compatibility, and is as close to what you can call a system component in virtually every distribution. There's no compatibility problem using GTK like you suggest. Moving fast isn't a problem as long as they don't break things.
Quote:
Have there been instances where a program written for SDL x.y didn't work with SDL x.z, with z > y?
All that above being said, I have seen intros fail to link because they've linked too specifically; e.g linked to a too specific soname, causing issues on distros that have moved to a newer SDL version that doesn't match any more.
But that's a fairly minor issue, and probably not intentional. And it's easy to work around with a local symlink and LD_LIBRARY_PATH.
Quote:
GTK provides backwards compatibility, and is as close to what you can call a system component in virtually every distribution. There's no compatibility problem using GTK like you suggest.
As someone who recently had to port the Amoeba configuration dialog box from GTK+ 2.0 to 4.0 because 2.0 is deprecated and going away, I beg to differ :-) (It was originally written for 1.1.)
Quote:
And it's easy to work around with a local symlink and LD_LIBRARY_PATH.
I wish demos would use -rpath $ORIGIN instead of having local launcher scripts…
Sesse: When you say "going away", what do you mean?
Sure, major APIs differ. That's kinda the point of major API changes. But there's tons of applications out there that's still using GTK+ 2.x, and I don't think the distros are removing packages for those, are they?
Sure, major APIs differ. That's kinda the point of major API changes. But there's tons of applications out there that's still using GTK+ 2.x, and I don't think the distros are removing packages for those, are they?
But also, it's not like SDL hasn't tried to chase people over from 1.x to 2.x forever either. SDL 1.x code has the same problems as GTK 2.x code, no fundamental change there.
Going away as in Debian (and probably others) will stop shipping it, as it is unsupported upstream.
IMO the best way for non-sizeentries is probably to link all support libraries statically. libGL, libc and libm are fine dynamically, the rest (SDL, libvorbis, GTK+, whatnot) should go with -Wl,-Bstatic -lfoo -lbar -Wl,--Bdynamic.
IMO the best way for non-sizeentries is probably to link all support libraries statically. libGL, libc and libm are fine dynamically, the rest (SDL, libvorbis, GTK+, whatnot) should go with -Wl,-Bstatic -lfoo -lbar -Wl,--Bdynamic.
+1 for "link statically if you can"; though I'd absolutely include libc/libm/libstdc++ as well.
Possibly libstdc++ too, yes. libc/libm are so stable that it's not worth it, and linking fully statically to them has their own problems (e.g. NSS, which must be linked dynamically).
Sesse: uh, so are you saying Debian is dropping LXDE support as well, then? Just checked, and for instance the lxpanel package depends on the libgtk-2.0.0 package in sid... That sounds... dubious to me. Do you have a link to some information on the removal?
The mass-filing is in bug #947713. It seems I misinterpreted the bug I received as an imminent deletion (which was wrong; there are no concrete plans for deletion, or at least were not in 2019), but it sure isn't in a healthy state.