Return to Part 1: Dumpster Diving
Continued from Part 45: Free as in Beer
Unlike when building a retro Windows computer which gives you certain milestone releases to target, the incremental nature of Linux leaves it more difficult to settle on which version you wish to run, even if you have decided on a distribution. I opted to use Red Hat Linux 7.3 Valhalla for largely two reasons: the decent 3D support it offers for my ATI Rage 128 Pro graphics card, and it still being on the right side of the glibc 2.3 boundary after which Loki Software titles will start to break.
Thanks to this I have had my fair share of success in running games released up to around 2004 or so, but after that I do begin to encounter more issues with binary compatibility. The true strength of Linux has always been in source compatibility however, and by leaning into this fact you can still find means and ways of getting newer games and software to launch, even if they were released well after the heyday of your chosen Linux version.
If you are given access to a source tarball with requirements already in line with your build environment, then this can often be as easy as just typing "make" and letting the magic happen. When playing with software from the future this often fails to be the case though, with new libraries being introduced and newer versions of existing libraries being demanded. At least when using an RPM based distribution such as Red Hat Linux, this is where source RPMs can become incredibly useful.
Not only do they give you all the benefits of package management such as proper dependency resolution, but by using source RPMs I have been able to version bump existing system libraries and even install new ones to those packaged for later Red Hat and Fedora releases, all without breaking compatibility elsewhere. Your mileage of course may vary, and a certain discretion is required, but one success I have had was in upgrading SDL to the version found in Red Hat Linux 8.0 Psyche.
My main interest was in trying to get SDL Mixer reliant games with MIDI music to utilize my hardware synthesizer, a feature in later SDL versions that I sadly still have not gotten to work, but in upgrading SDL I was also able to finally build and then play the 1.0.0 version of Frozen Bubble outside of a live Knoppix environment. To do this I needed to grab the SDL-1.2.4-5.src.rpm, SDL_image-1.2.2-3.src.rpm, SDL_mixer-1.2.4-5.src.rpm, and SDL_net-1.2.4-3.src.rpm files from the Red Hat archives.
To build and install a source RPM on Red Hat Linux 7.3 you need to use the "rpm --rebuild" command followed by the name of the package files in question, which if successful will generate regular binary RPM packages in the /usr/src/redhat/RPMS/i386 directory. Assuming there are no conflicts you can then use these to install or update your software, although in this case I did need to ensure that the SDL and SDL-devel packages were installed first in order to respect the depedency chain.
Building SDL also required nasm to be installed as a dependency, and the Frozen Bubble source RPM package that I used also needed the desktop-file-utils-0.2-1.i386.rpm package to be installed, all of which was communicated by the package manager saving me any guesswork. The main stumbling block I always had when trying to build Frozen Bubble in the past was perl-SDL, but with the newer version of SDL installed, I was at last able build a perl-SDL source RPM without incident.
The Enet library served a similar role in blocking my ability to compile the final release of Cube, but by grabbing a source RPM from when it was included with Fedora 7 Moonshine I was at last able to get it to build. Overall performance is weaker than in the earlier release I covered, as while Cube remains playable it dips into uncomfortable frame rates far more often. I do feel the game plays smoother at 32-bit colours, as I found with Unreal Tournament, but the difference here was marginal.
In accomplishing this I corrected what were two of my greatest failures in getting newer releases of games to run, but I was not able to redress everything. Newer versions of ClanLib are built with X.org rather than XFree86 in mind, meaning I was unable to get later versions of Trophy to work for instance. Attempts at using later Kobo Deluxe source RPM packages also just produced the same errors related to GL detection that I got when I tried to build them with the source tarballs.
Now that I have the binary RPM packages created for Red Hat Linux 7.3 Valhalla I can just distribute them to save anyone else the trouble, but there are lessons to be learned here for anyone trying to run new software on legacy RPM based distributions; source RPMs for Mandrake and its descendants are not compatible with Red Hat however, and Debian and derivatives possess their own separate ways of handling package sources. Time to tackle a different challenge, and look back in time instead.
Carrying on in Part 47: Before I Was Born
Return to Part 1: Dumpster Diving
One technical question: When upgrading libraries like SDL from Red Hat 8.0, how do you manage potential conflicts with software that still relies on the older versions? Do you use symlinks or isolate environments, or is there a method to ensure system stability while updating?
Sticking with XFree86 and the ATI Rage 128 Pro is a nostalgic touch — I’ve heard that card was incredible for its time!
https://icculus.org/~hamish/retro/part46.html
> One technical question: When upgrading libraries like SDL from Red Hat 8.0, how do you manage potential conflicts with software that still relies on the older versions? Do you use symlinks or isolate environments, or is there a method to ensure system stability while updating?
Really the package manager takes care of that within reason. In the case of SDL I just removed the original SDL packages and any dependencies, and then installed the new packages in their place along with whatever packages I was told were removed. That I was able to install yum thanks to Fedora Legacy helped a lot with this.
See more from me