|
|
Log in / Subscribe / Register

GIMP 0.54.1 in a Flatpak

[Posted June 22, 2026 by jzb]

The GIMP project reports that GNOME contributor "balooii" has worked to package GIMP 0.54.1—released in 1996—as a Flatpak that will build and run on modern 64-bit Linux systems. This is a Motif-based version, and the same version that was used by Larry Ewing to create Tux.

While not likely to be useful for serious graphics work today, it should be interesting for users who would like to see what a 30-year-old version of GIMP was capable of.


to post comments

lesstif

Posted Jun 22, 2026 21:43 UTC (Mon) by ballombe (subscriber, #9523) [Link]

We had to use lesstif because motif was non-free (it is free now).

Heavily patched for 64-bit

Posted Jun 23, 2026 9:32 UTC (Tue) by Tarnyko (subscriber, #90061) [Link] (15 responses)

I remember very well this code compiled fine but crashed a lot on 64-bit. As expected there were lots of assumptions about running on 32-bit, that the Flatpak fixes with a bunch of "LP64"-labeled patches; this is appreciated.

Heavily patched for 64-bit

Posted Jun 23, 2026 15:50 UTC (Tue) by epa (subscriber, #39769) [Link] (14 responses)

I guess this could be a use for that x32 architecture mentioned on LWN recently -- to run old 32-bit code, without having to debug and fix it to be portable to 64-bit. Although you have to drag in all your libraries built for x32, that is what Flatpaks are good at.

Heavily patched for 64-bit

Posted Jun 23, 2026 16:11 UTC (Tue) by ballombe (subscriber, #9523) [Link] (7 responses)

You would need a kernel that has not disabled support for x32. Most distro kernel disable it.

Heavily patched for 64-bit

Posted Jun 24, 2026 20:06 UTC (Wed) by WolfWings (subscriber, #56790) [Link] (6 responses)

x32 has nothing at all to do with i386-era 32-bit code compatibility.

Heavily patched for 64-bit

Posted Jun 25, 2026 1:47 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (5 responses)

Are you replying to the wrong comment? This was in reply to an explicit query whether x32 would be useful here.

Heavily patched for 64-bit

Posted Jun 25, 2026 5:45 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (4 responses)

But the grandparent comment was about running "old 32-bit code" and using x32. Both are different architectures.

Heavily patched for 64-bit

Posted Jun 25, 2026 7:37 UTC (Thu) by epa (subscriber, #39769) [Link] (2 responses)

I meant old code where you have the source, and can recompile it for either i386 or x32, but trying to compile and run it on 64-bit platforms doesn’t work because the code makes assumptions about pointer size. In that case building for x32 seems a slightly cleaner option, and the extra performance might be useful, depending on the application.

If you have only an old binary then yes, an i386 architecture Flatpak would be the way.

Heavily patched for 64-bit

Posted Jun 25, 2026 7:53 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

But x32 still requires you to check assumptions about integer sizes in certain cases, e.g. time_t is 64bit so that wouldn't help you avoid that examination of the old code.

Heavily patched for 64-bit

Posted Jun 25, 2026 7:54 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

And it also requires you to have a kernel that supports x32, which most people don't have, which is how we started this subthread

Heavily patched for 64-bit

Posted Jun 25, 2026 7:49 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Old 32-bit code built for x32 is x32, not i386.

Heavily patched for 64-bit

Posted Jun 23, 2026 16:27 UTC (Tue) by mb (subscriber, #50428) [Link] (5 responses)

Why not compile for ia32 an drag in all ia32 libs?
I don't think x32 does any good here. The performance benefit doesn't matter for historical software.

Heavily patched for 64-bit

Posted Jun 23, 2026 19:27 UTC (Tue) by joib (subscriber, #8541) [Link]

Indeed. Hard to see this as any kind of win for x32.

Heavily patched for 64-bit

Posted Jun 24, 2026 9:59 UTC (Wed) by epa (subscriber, #39769) [Link] (3 responses)

For an image processing program like the GIMP, the performance benefit could matter. I agree for an old word processor it would not. For an old spreadsheet program, again, you might want to run it as fast as possible.

I am thinking of the legacy systems you sometimes come across, where somebody set up a process in 1994 and it has hardly been touched since, but the volume of data it has to handle has grown a hundredfold.

You are saying to use the i386 architecture instead of x32, if you don't want to make the old code portable (or perhaps you don't even want to recompile it, having only an old executable). I agree that could be the most practical way forward.

Heavily patched for 64-bit

Posted Jun 24, 2026 10:13 UTC (Wed) by mjg59 (subscriber, #23239) [Link]

The performance difference between going from a 1994 CPU to a modern CPU is going to be so ludicrously large in comparison to the benefit of more registers that I suspect anyone who was putting up with still running on ancient hardware is going to be just fine without x32

Heavily patched for 64-bit

Posted Jun 24, 2026 15:33 UTC (Wed) by smcv (subscriber, #53363) [Link] (1 responses)

x32 isn't ABI-compatible with i386 (for example time_t is 64-bit on x32 but 32-bit on i386), so using x32 wouldn't address all of the word-size assumptions of a 30 year old codebase anyway.

Heavily patched for 64-bit

Posted Jun 25, 2026 7:38 UTC (Thu) by epa (subscriber, #39769) [Link]

Thanks, that’s a good point.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds