Best Practices for Installing Newer Dev Libraries Not Available in Official Repositories

Yo! I recently transitioned to Zorin OS from Fedora due to an update mishap. As a game developer, I've been working with SDL2, specifically version 2.26, on my Fedora setup.

I've noticed that the version of SDL2 available through Zorin's package manager is somewhat outdated. While I could compile SDL2 myself, I'm a little hesitant to do so. My concern is about keeping my system clean and avoiding unnecessary bloat that would come with this, especially since I've just set it up. Also I enjoy being able to keep up with and update my development libraries using the built in package manager tools that a program comes with instead of having to manually manage different update methods for different libraries.

This leads me to a broader question: What are the recommended practices for installing newer versions of development libraries that aren't available in the official repositories? Is there a PPA or another trusted repository that you'd recommend for this purpose? Or are there updates planned that will bring newer versions of such libraries, like SDL2, to the official repositories?

I appreciate your time and assistance in helping me navigate this. Aside from this niche issue using Zorin has been an incredibly seamless experience so far and I really appreciate all the work that has gone into making it the great experience that it has been.

1 Like

Zorin OS 16 is based on Ubuntu 20.04, which may be why some packages seem older.
Zorin OS 17 (in current development) will bring more up to date LTS packages.

I am not aware of a Specific PPA where you can turn to for dev packages. I install any I need from the main repo and I have never had any issues. Such differences are made when people work on different projects...
I rely on for finding most any .deb package.

SDL 2.26 is currently only available on Ubuntu and Ubuntu based distros in 23.04 (Interim non-LTS) release. It is not even on Ubuntu 22.04, which is using SDL 2.20.

Here is the .deb download link for 2.26:

I checked it out and it says that all dependencies are satisfied to install on Zorin OS 16.3

1 Like

Thanks for responding, I looked at the link you sent, and realized(after installing lol) that it was the sdl2-doc deb. So I decided to look through and found libsdl2.26 on it and downloaded it. However I used dkpg-deb to check its dependencies before installing and it seems like the library needs libc6 to be on version 2.34 or greater. And a quick search seemed to indicate that upgrading that would break everything. So should I just bite the bullet and try compiling it myself using libc6 2.31? Or do is there anything else I can try?

1 Like

ack. My mistake. I seem to have clicked the Second Link on the list instead of the first.

Do not try to upgrade Libc6 to 3.34 - that would definitely break everything.
You could try extracting the package and in the Control file, changing the depends portion to be libc6 (>= 2.31)
Then debuild the package back into a .deb and try installing - that is risky, though. Back up your data and be prepared to either troubleshoot or reinstall in the worst case.

Would it be possible to work with the libc6-dev, possibly in a virtual environment, to accomplish your work and test in a virtual machine? I ask because I've also installed and used newer libraries to create software. While I couldn't test it outside of a virtual environment, vscode and virt env easily allowed this as long as the package directory was in PATH.

It will be some time before LTS releases get this version of the library.

While this isn't a solution to your issue, it is a workaround in order for you to continue working in Zorin.

1 Like

I'm also curious, what functions are you using that are specific to the libc6 2.35 library that you cannot code either for multiple versions or create a derivative of the functionality you need?

Oh well, weighing my options, and what would cost me the most time, I just decided to write a wrapper function that checks the SDL version at compile time and handles the missing feature. Especially after further investigating and finding out that the only real lose was SDL_getTicks64() which I was using as SDL documentation advised not using the old version since it would wrap after awhile, however after further reading the documentation it only wraps after ~49 days, and while I would like to be able to create programs that could run stable for any amount of time, I suppose 49 days is an acceptable limitation for now lol. Thanks for the help, and also the link, I've bookmarked it and will use it next time I need a newer version of a package.