search

TerryCavanagh / VVVVVV

The source code to VVVVVV! http://thelettervsixtim.es/
Other
7k stars 559 forks source link

SDL in Ubuntu stable releases is too old #618

Closed Daaaav closed 2 years ago

Daaaav commented 3 years ago

These commits added the use of SDL_zeroa(): 70b9ffe6a58b71122aa60280bae4194326d026a0 a113662050d29a01819a2f606c9bb1d55d941abb bd97378862c6b01d1de59f59a98a8a53a74fb696

The 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 via apt 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.

flibitijibibo commented 3 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.

Daaaav commented 3 years ago

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.

leo60228 commented 3 years ago

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.

dsalt commented 3 years ago

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).

leo60228 commented 3 years ago

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.

InfoTeddy commented 3 years ago

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?

LoganDark commented 3 years ago

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.

InfoTeddy commented 3 years ago

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?

Daaaav commented 3 years ago

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).

LoganDark commented 3 years ago

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).

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.

stephendcofer commented 2 years ago

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.

InfoTeddy commented 2 years ago

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".

flibitijibibo commented 2 years ago

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.)

InfoTeddy commented 2 years ago

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.

leo60228 commented 2 years ago

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.

— 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.

Daaaav commented 2 years ago

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).

InfoTeddy commented 2 years ago

(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)

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 cmakeing VVVVVV.)

Daaaav commented 2 years ago

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.

InfoTeddy commented 2 years ago

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.

InfoTeddy commented 2 years ago

Actually, looking at the savoury1 PPA some more, the package details for libsdl2 say that it includes libsdl2-dev as well:

libsdl2-dev

Can someone who has an Ubuntu box check if installing this PPA will let them install libsdl2-dev 2.0.16?

Fussmatte commented 2 years ago

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.

InfoTeddy commented 2 years ago

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).

leo60228 commented 2 years ago

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.

InfoTeddy commented 2 years ago

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

  1. Install the savoury1 multimedia PPA, which makes the latest 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.

  2. Install Homebrew for Linux. Then it's just a simple brew install sdl2.
  3. 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.

leo60228 commented 2 years ago

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

  1. 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

  2. Install Homebrew https://brew.sh for Linux. Then it's just a simple brew install sdl2.

  3. 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.