Closed Daaaav closed 2 years ago
Has a report been filed to Canonical to update to 2.0.14? If we can fix it on that end instead that'd be preferred, as we'll eventually be moving to 2.0.16 for some stdlib functionality anyhow.
I don't know about any method to file a report to Canonical or where to find out whether anyone has done it, but in my experience it's pretty standard that they keep packages on whichever version was latest before the original date of that Ubuntu release (unless required for security), and only newer releases get newer versions.
Packages will only be backported into Ubuntu itself due to major bugs, however users can opt-in to updating specific packages through the Ubuntu Backports Project.
requestbackport
in the ubuntu-dev-tools
package is an interactive tool for submitting backport requests with the required metadata.
I have SDL 2.0.14 installed here, and I doubt that I'll be updating past that before Debian's next release (though I'm actually using Devuan) – and if I do it'll most likely be via backports.
The only times that I've seen newer versions being pulled into an existing distribution release are to pull in some security bug fixes but the fixes are too big or too invasive for the maintainers to handle as patches.
(Incidentally, Debian's previous release, buster, has SDL 2.0.9.)
Regarding SDL_zeroa
, if there's nothing else being used which isn't in 2.0.12, you could get away with including (after SDL includes) a compatibility header file containing
#ifndef SDL_zeroa
# define SDL_zeroa(x) SDL_memset((x), 0, sizeof((x)))
#endif
(on the assumption that 2.0.12 has SDL_memset, which seems likely).
For what it's worth, 2.4 will likely require 2.0.18/2.0.20 due to action sets, and it won't be easy to backport.
I'd also like to mention that with the new VSync API merged into SDL 2.0.18, 2.4 has already dumped the VSync renderer workaround in favor of that API (see 6ba7058a0eddd0f1f2e6dab8d01546dfc033cb58). Right now, we have a #if
, so this doesn't cause builds to fail, but it does mean builds compiled on an SDL older than 2.0.17 cannot toggle VSync in-game. And of course, that #if
will go away and we will start hard-requiring 2.0.18 when 2.0.18 releases.
I also upgraded the minimum version to 2.0.16 due to using some new stdlib functions that got merged in that version as well (see c94d04a932b0bb90d3ede1d3a90c1a42b05404bc). Really the only reason I hadn't done it earlier was because CI would fail otherwise (Windows's vcpkg
takes a while to update their SDL, apparently...), and I had to figure out how to run Docker to update the Linux container (it involved me reconfiguring my kernel).
But my point is that this problem will more-or-less only get worse in the future as SDL and VVVVVV development continues. Since it doesn't seem like Ubuntu is going to have backports for those versions, it seems to me that the next best thing would be for someone to maintain a PPA with the latest stable SDL release. I would do it if I used Ubuntu, knew how to do it, and didn't find it much of a hassle to do. Anyone here willing to try a PPA? Or is there something else we can do here?
Linuxbrew allows you to install the latest SDL extremely easily. It's just brew install sdl2
, it will compile the latest version from source if it has to, but for Ubuntu there are probably already prebuilt binaries.
Support in apt
is not required, and hasn't been in a while. Use Linuxbrew if you need to compile things, it makes things way easier.
Homebrew does sound way easier than having to manually download all build dependencies and compile SDL yourself... @Dav999-v, does this solution work for you?
Personally I'd like to avoid bloating my system unnecessarily, so I'd think really well about installing something like Homebrew over just compiling SDL myself instead, but for people who don't care as much about that, it's certainly an option. A PPA for recent SDL versions would also be nice (apparently there is one with a lot of packages including SDL 2.0.16 here, but it seems to have only libsdl2
and not libsdl2-dev
, so if I'm not mistaken that would only help if VVVVVV didn't come with a .so
for SDL, but it does).
Personally I'd like to avoid bloating my system unnecessarily, so I'd think really well about installing something like Homebrew over just compiling SDL myself instead, but for people who don't care as much about that, it's certainly an option. A PPA for recent SDL versions would also be nice (apparently there is one with a lot of packages including SDL 2.0.16 here, but it seems to have only
libsdl2
and notlibsdl2-dev
, so if I'm not mistaken that would only help if VVVVVV didn't come with a.so
for SDL, but it does).
Homebrew is not only useful for SDL. If you compile from source frequently, or even at all, the best way to keep these resources on your system up-to-date is Homebrew, not your distro's package manager. Think of it as a new tool to add to your arsenal - not just for installing this one library. Having it on your system, even though it takes a gigabyte or two, is a huge help.
The fact that it helps with this specific scenario, and that this scenario may be how you discovered it in the first place, is just a bonus.
Also even on latest Ubuntu (21.10) SDL_isxdigit isn't available since 21.10 uses SDL2 2.0.14 and it and related new "is characteristic" stdlib functions in SDL was added in 2.0.16, breaking compilation even on latest Ubuntu. Not going to risk breaking anything by manually upgrading SDL to a non-Ubuntu version or waste time hackishly throwing in different versions with things like homebrew; I just added the SDL_isxdigit function to desktop_version/src/UtilityClass.cpp as a hack to get it to build on even the latest, newest version of Ubuntu. Bad practice to throw in brand new functions from versions of libraries that aren't even on most distros yet.
Bad practice to throw in brand new functions from versions of libraries that aren't even on most distros yet.
Then how do you suggest we toggle VSync? As I noted above, SDL 2.0.18 has a new dedicated VSync toggle function, to fix a problem where toggling VSync required a hacky workaround by tearing down everything and rebuilding (which didn't work on some systems). It's hidden behind a #if
until 2.0.18 releases.
Also, you said "libraries", plural, but we only have external build dependencies for SDL2 and SDL2_mixer (and SDL2_mixer is going to be axed in favor of statically linking FAudio) - all other dependencies have had their source copied in and are statically linked by default - so arguably, we only have one library with "brand new functions [...] that aren't even on most distros yet".
I also question the "most distros" part, because as far as I know the following all have 2.0.16:
As far as I know it's just Debian-based and RHEL-based, and only at the system repo level (developer environments like the last two above are fine). Even as a CentOS 7 user myself it's not that big of a deal to self-build libraries that I expect to use regularly (and for releases we provide SDL ourselves anyway).
(And frankly I don't care that Ubuntu falls into the Debian umbrella - user support for Ubuntu and friends is 99% linking people to PPAs like kisak-mesa, so having this be the experience for developer support as well is no surprise to me.)
I also question the "most distros" part, because as far as I know the following all have 2.0.16:
Almost all of these can be easily verified using Repology.
~ equery y libsdl2
Keywords for media-libs/libsdl2:
| | u |
| a a p s a r | n |
| m r h p p l i i m m s | e u s | r
| d a m p p c a x p a s 6 i 3 | a s l | e
| 6 r 6 p p 6 r 8 h 6 c 8 p 9 | p e o | p
| 4 m 4 a c 4 c 6 a 4 v k s 0 | i d t | o
-------------+-----------------------------+-------+-------
[I]2.0.16-r1 | + + + ~ + + + + ~ ~ ~ o o o | 8 o 0 | gentoo
NixOS has an open PR for updating SDL to 2.0.16, but there were issues with the libdecor dependency. It looks like those should be solved soon, though.
On Fri, Nov 5, 2021, 12:56 PM Misa Elizabeth Kai @.***> wrote:
I also question the "most distros" part, because as far as I know the following all have 2.0.16:
Almost all of these can be easily verified using Repology https://repology.org/project/sdl2/versions.
Gentoo: https://packages.gentoo.org/packages/media-libs/libsdl2, and I can personally confirm this because I use Gentoo
~ equery y libsdl2
Keywords for media-libs/libsdl2:
| | u | | a a p s a r | n | | m r h p p l i i m m s | e u s | r | d a m p p c a x p a s 6 i 3 | a s l | e | 6 r 6 p p 6 r 8 h 6 c 8 p 9 | p e o | p | 4 m 4 a c 4 c 6 a 4 v k s 0 | i d t | o
-------------+-----------------------------+-------+-------
[I]2.0.16-r1 | + + + ~ + + + + ~ ~ ~ o o o | 8 o 0 | gentoo
Slackware: 2.0.16 but no link on Repology
Void: https://github.com/void-linux/void-packages/tree/master/srcpkgs/SDL2
OpenBSD: https://openports.se/devel/sdl2
FreeBSD: Testing stage isn't listed on Repology, but I did find this bug report https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252371
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/TerryCavanagh/VVVVVV/issues/618#issuecomment-962058538, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7X32ISBQ2T7EGSOMEUP5TUKQLFVANCNFSM4XWUNSQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
As for me (since I opened this issue), I went with just compiling SDL myself. All I did was remove apt's versions of SDL, SDL_mixer and SDL_image, then apt install
all the packages that it says are no longer necessary (to mark them as manually installed) and then just ./configure
, make
and sudo make install
SDL and SDL_mixer. I've had no problems so far, but if you ever want to go back to apt's version, you can always sudo make uninstall
.
The most straightforward resolution I originally started this issue for (just sticking to an older SDL version in VVVVVV for compatibility) seems to be a WONTFIX, at least for now - the VSync thing and action sets kinda make it unattractive to stick to an older version here, but of course it's always possible to slow down our SDL version requirements from this point onwards and let the problem go away again by itself in a year or so (or at least not let stuff like c94d04a932b0bb90d3ede1d3a90c1a42b05404bc determine the minimum version when it's arguably not worth it).
(apparently there is one with a lot of packages including SDL 2.0.16 here, but it seems to have only
libsdl2
and notlibsdl2-dev
, so if I'm not mistaken that would only help if VVVVVV didn't come with a.so
for SDL, but it does)
Revisiting this... As far as I know, the only difference between libsdl2
and libsdl2-dev
is that libsdl2-dev
provides the header files in /usr/include
. As you imply yourself, libsdl2
only provides the .so
. (Also, libsdl2-dev
provides a .a
file for static linking, but we don't statically link SDL.)
So if this is all that your problem is, then can't you just copy the SDL2 header files to /usr/include
? (And if you don't want unmanaged header files, then, just put them somewhere nice and use the -DSDL2_INCLUDE_DIRS
CMake option when cmake
ing VVVVVV.)
Hm, I guess that's another option that people might feel more comfortable with then.
Isn't it an option likewise to manually compile SDL but not install it system-wide, and then pass cmake
some more arguments to point to your compiled version? -DSDL2_LIBRARIES
, from a quick look? If that works, it's probably gonna be the most reassuring option out there for anyone.
Yes, -DSDL2_LIBRARIES
should work too, then.
If those options work for everyone, then I think we should close this issue as fixed. Namely, you can either compile SDL or grab the .so
from somewhere (such as the Steam release, or the savoury1 PPA). Then install SDL system-wide, or use the CMake variables -DSDL2_INCLUDE_DIRS
(after placing the downloaded header files somewhere okay) and -DSDL2_LIBRARIES
. Or use Homebrew.
Unless someone really really wants a libsdl2-dev
PPA, I don't think there's much else we can do, short of twisting the arms of Canonical.
Actually, looking at the savoury1 PPA some more, the package details for libsdl2
say that it includes libsdl2-dev
as well:
Can someone who has an Ubuntu box check if installing this PPA will let them install libsdl2-dev
2.0.16?
Can someone who has an Ubuntu box check if installing this PPA will let them install
libsdl2-dev
2.0.16?
Not sure if it's too late to confirm, but installing that PPA did let me upgrade my SDL2 packages so that the game could successfully compile.
It's not too late, but I'll take that as confirmation that the savoury1 PPA does provide libsdl2-dev
, and not merely libsdl2
(without the headers).
Actually, looking at the savoury1 PPA some more, the package details for libsdl2 say that it includes libsdl2-dev as well:
This is because compiling SDL2 produces both packages. It'd be kind of silly to build it twice, once just for the headers.
Okay, so, at this point, unless Canonical is willing to change (which, speaking from personal experience, institutions are big and dumb and not likely to do that), and you don't want to upgrade to an unstable version, or don't want to switch distros, there are many workarounds to get the latest version of SDL on Ubuntu (in order of easiest to hardest):
libsdl2-dev
available.
sudo add-apt-repository ppa:savoury1/multimedia
sudo apt-get update
Make sure to run sudo apt-get install libsdl2-dev
again after doing this.
brew install sdl2
.cmake
the game, use the -DSDL2_INCLUDE_DIRS
and -DSDL2_LIBRARIES
variables to point to your copy.With the VSync stuff and potentially having action sets, we are not going to be slowing down SDL upgrades anytime soon. (And there's no telling that we may need something new from SDL in the future, too.) All I can say is to just be glad that we're not using, like, C++9999 or whatever, or Rust nightlies.
Rust nightlies
I mean, Rust nightlies are easy for end-users, and every distro can handle them because of Firefox.
On Sun, Nov 14, 2021, 1:06 PM Misa Elizabeth Kai @.***> wrote:
Okay, so, at this point, unless Canonical is willing to change (which, speaking from personal experience, institutions are big and dumb and not likely to do that), and you don't want to upgrade to an unstable version, or don't want to switch distros, there are many workarounds to get the latest version of SDL on Ubuntu (in order of easiest to hardest):
Install the savoury1 multimedia PPA https://launchpad.net/~savoury1/+archive/ubuntu/multimedia/, which makes the latest libsdl2-dev available.
sudo add-apt-repository ppa:savoury1/multimedia sudo apt-get update
Install Homebrew https://brew.sh for Linux. Then it's just a simple brew install sdl2.
Manually download the latest SDL and compile it from source.
- If you don't want to install it system-wide (which would mean having an unmanaged package), then when you cmake the game, use the -DSDL2_INCLUDE_DIRS and -DSDL2_LIBRARIES variables to point to your copy.
With the VSync stuff and potentially having action sets, we are not going to be slowing down SDL upgrades anytime soon. (And there's no telling that we may need something new from SDL in the future, too.) All I can say is to just be glad that we're not using, like, C++9999 or whatever, or Rust nightlies.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/TerryCavanagh/VVVVVV/issues/618#issuecomment-968338212, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7X32KBYK4RUZJT7KXOKTDUL73CBANCNFSM4XWUNSQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
These commits added the use of
SDL_zeroa()
: 70b9ffe6a58b71122aa60280bae4194326d026a0 a113662050d29a01819a2f606c9bb1d55d941abb bd97378862c6b01d1de59f59a98a8a53a74fb696The problem is that
SDL_zeroa()
was added in SDL 2.0.12, and the earliest version of Ubuntu that can easily install SDL 2.0.12 viaapt
is the very latest, Ubuntu 20.10 (see 20.04 and 20.10), and 20.10 is not an LTS version.So now anyone on most versions of Ubuntu or related distros (or anywhere else an earlier SDL is used than March 2020) will get a compilation error and will have to be told their SDL is too old. This makes "just" compiling VVVVVV more difficult on those systems.