I would prefer for feature to exist and work and don't care if the buttons look the same. I am super salty because I tried to run some old 32 bits qt4 and gtk2 python apps on latest Kubuntu LTS (I am 100% only Linux for years )and I just wasted hours without any satisfaction, at least on Windows 10 year old programs will still work most of the time(probably some old games could fail but might be a driver issue and not a Microsoft stuff).
If it's dependencies and packages no longer being shipped, you'll have the same issues running those Python programs on Windows and probably the same solutions as well (downloading all the old sources, compiling all the libraries manually).
You can still run the x86 ABI on x64 (or any other architecture through qemu) though unlike Windows, most Linux distros don't ship support for it by default.
The programs themselves work, but the dependencies have moved on. This is why many recent ecosystems are focusing on static compilation, only demanding a very basic minimal set of functionality (C runtimes and such) from the OS at the cost of needing to patch every single binary on your system one by one when the next log4j/heartbleed bug hits.
This stuff is also why I dislike Python as a platform for running GUI applications. It's easy and it works assuming you put in the work to maintain compatibility yourself. Compiled binaries will work for much longer.
For Windows Qt developers will put the Qt dlls in the application , not statically link. So in general you will probably be able to run an old Qt app on Linux by using Wine.
Yeah, the issue is missing dependencies, the 32 bit versions, Linux Gamers complained so there still are some 32 bit packages around but not all of them.
Compiling this old apps I assume will hit same issue, this time missing even more packages since I will need all GTK2 dependencies. I wish there was a nice, slim way to put in a folder all the libraries from a say 16.04 release and tell this app to look there in that folder.
App images would probably be the solution, but who will find all those old projects from source forge that have very few users and rebuild them?
It's not like Linux doesn't allow you to put the QT .so files next to the binary either, Linux applications generally just expect these files to be available system wide.
> Compiling this old apps I assume will hit same issue, this time missing even more packages since I will need all GTK2 dependencies. I wish there was a nice, slim way to put in a folder all the libraries from a say 16.04 release and tell this app to look there in that folder.
LD_LIBRARY_PATH can be your friend. You'll still have to reconfigure the application for other resources like images, but as far as libraries go it's a pretty useful fix. I've used it before because the default libraries that come with Google's Android emulator just refuse to work on my system. The easiest way is probably to add the variable to your .desktop file or to write a script that sets it and forwards all arguments to the real binary.
> App images would probably be the solution, but who will find all those old projects from source forge that have very few users and rebuild them?
I agree; Flatpak and friends are a great way to keep applications working many years down the line. I expect them to only stay available for newer programs, though.
You can set up a Docker pipeline that will build the application of your choosing and use that to release updates of old programs but in the end you're still going to need someone who will do that for you.
That said, GTK2 is one of those libraries that'll still be packaged with operating systems for a while, it's just the unmaintained dev version that gets left behind. Like with Python 2, nobody wants to maintain that old stuff so it's either up to the devs to update or up to you to come up with ugly hacks to still run the old software (at your own risk, of course).
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;
isnt that was flatpak and snapimg are suppose to solve, making linux apps more like windows apps in that all dependence are included with the app distribution not dependent on system wide installation?
which is ironic since more and more apps on windows require various system wide dependencies like dotnet, c++ resitibutables etc,
More than a few apps I have tried to install recently on windows would not just run because dotnet 3 is missing by default on both win10 and win11
Which might bite us in the future. I just had an issue with a Snap app that hung in some scenarios when it used OpenGL. In the end it turned out that the Snap app packaged an outdated version of Mesa (graphics driver) which didn't handle my GPU properly.
