The fact is that is usually done in the Linux ecosystem: if you have access to the source code, what is the pro? It's just simple to recompile the software targeting the release of the operating system you are using. By dynamically linking system libraries you will get smaller executable and save RAM since they are shared (not only on disk, but also in memory, that is what shared means!)
I dread every time I need to install a (older) package from source. I think around a quarter of the time it turns into a multiple hour adventure of frustration, only to discover the library it was missing is called $NAME-dev on my distro...
You lost me at this part: if the dependency is easy to install and the issue is you just don't know that all of the headers are in -dev packages this seems like the easiest problem to never have again. Really: right up until there I was rooting you on.
For code, you can compile by specifying the correct C standard. Unless the build system is badly written and doesn't add the correct -std=cXY to gcc of course (but it's trivial to fix).
Regarding libraries, that is a real problem. Because to compile and old software you should use old version of the libraries, and they are usually not easy to get (and then it's a pain to compile them, and put the correct environment variables to make the software you are building link to that libraries and not the one in the system).
I'm always able to compile a software, even an old one, on my system, and it never took me more than a couple of minutes. But I recognize that I'm a pretty experienced Linux user, so sure for the average user having a binary package is more easy.
The waste of time to compile anything is staggering. And more often than not I give up on failure after 2h. Because one of the recursive depency is impossible to build. Or I got tired of git cloning or wget'ing 50 differents stuff.
Sometimes it will ends with: XXX is missing, required version mismatch, install correct version, your computer crash.
I dread the day we have to put together an installer for it. If we ever decide to use GTK on all platforms we'll have to since the GTK developers don't seem to think static linking is a useful thing for them to support.
The GTK folks oppose static compilation, and that's a perfectly fine point of view because they can support their opinions quite well. However, without an official "Microsoft visual c++ runtime" equivalent, distribution of GTK apps is just so annoying on Windows! You can get the entire GTK library suite just fine on most Linux distros but when it comes to non-Linux platforms, you're left to your own devices, and that means every platform comes up with its own solution, incompatible with the rest.
I'm not sure it really matters, in the end. How often would people want to run PowerPC-era Mac software on modern hardware natively if they could? The HN audience will include a disproportionate number of people who do, so you guys aren't included ;-)
I haven't used a Mac in several years but it seems like the whole Apple mindset is more appliance like, that if you bought old software you just keep running it on the original old hardware, and given the problems with Microsoft's eternal backwards compatibility approach (applications and the OS bundling forever ancient code and keeping ancient interfaces around forever, and ending up with a disproportionate number of API calls numbered foo2, foo3, foo4ex), I'm not sure either way is strictly superior to the other. There are trade-offs with both.
I think some creative people, e.g. writers, might like to be able to continue to run their favorite old word processors if they could. Every so often you'll hear about a writer who's still using Wordstar or WordPerfect or some other old software because they know it inside out and it does what they need.
Of course, using old hardware has plenty of disadvantages (the increasing scarcity over time as parts become impossible to acquire) but even now you can find power macs for cheap. Your average ebay listing is pretty ridiculous but I snatched a G4 ibook there 2 years back for $14 USD, essentially in like new condition.
Korg released an audio DSP playground in a PCI card called the OasysPCI which never got OSX drivers, so I have a MDD PPC Mac to run that. There are probably better things running natively today, hey instruments are things that shouldn’t be obsoleted, since they all have their own sound. Most of the rest of the ancient software I run is run under Wine (which worked quite well up to Mojave, but became difficult when Apple killed 32 bit support) because Microsoft has done better at retaining backwards compatibility. So now I have a laptop permanently stuck on Mojave.
And it's not an academic one - a large percentage of somewhat older Mac-native Steam games don't even start.
It includes much more recent software too. It seems like half the mac games on Steam are 32-bit binaries published before October 2019 that no longer run on modern versions of macOS.