One question, so if I copy the old libraries from an old distro, will they fail because on my distro there is a new libc or libc++ ? Because I hit this issue too where from my googling you can only have one libc(or c++ I can't remember, but I was forced to upgrade because a software needed a newer library and it was no way to provide a non system wide one -or not an easy way that I could actually find).
In my case I run this python2.4 app, it complained about a missing library, I googled it, found what package had it, installed it, then repat and repeat.
Now I am stuck at "libpangox1.0" can't find it on the apt repos , so maybe I will waste more time on google or just give up.
Is a good lesson as a developer, either use some "modern" stuff or if you use c/c++ and care about the users try to build an AppImage or something similar.
You can copy over the old libraries, but you also need to copy the dependencies of those libraries and their dependencies. This can even include the old version of libc if the compiled binary doesn't have any special configuration built in.
Your libpangox library can be downloaded from Debian it seems. In most cases, Debian and Ubuntu libraries work pretty well together (as long as you don't install them at the system level). Unpacking the contents and putting them in the right (application specific) paths may solve your problem.
Personally, I'd resort to setting up a virtual machine for software that old, maybe running X11 forwarding to get the GUI on my native desktop. You might also get away with setting up an AppImage/Flatpak image you can then use on your desktop but that'll take even more fiddling around.
If you're in luck, you may also be able to install the modern equivalent of these packages and port the software over. How well that works really depends on the complexity of your application, but I've run old software after fixing a few imports and method names before so it's worth looking into perhaps?
Personally, I don't really like scripting languages for complex tools like GUIs exactly for this reason. Python in particular depends on a lot of native libraries for its script-to-native conversion, which means you need the perfect mix of language support and dynamic library support for old code to work. It's not a problem if your tool is being maintained, but if it's using software as old as Python 2.4, you're often up for one hell of a challenge. Super basic programs with rudimentary GUIs will work easily but once GTK and Qt get involved, you're probably better off with a compiled binary in my experience;
In my case I run this python2.4 app, it complained about a missing library, I googled it, found what package had it, installed it, then repat and repeat. Now I am stuck at "libpangox1.0" can't find it on the apt repos , so maybe I will waste more time on google or just give up.
Is a good lesson as a developer, either use some "modern" stuff or if you use c/c++ and care about the users try to build an AppImage or something similar.