Debian removes FPC/Lazarus

[Martin_fr]

While technically possible does not mean that it's feasible. For the LCL it simply is not worth the effort this would require.

PascalDragon: are you also one of the Lazarus developers? i thought you were on 'team FPC'.

the advantages seem enormous, not only does it solve the Debian issue, it also yields ELF binaries that are far more universal, in the sense that they will run against multiple widget sets. and it is a chance to begin cleaning out all but the GLIBC dependencies from the ELF Symbol Table.

on the other hand, since the vast majority of Lazarus/FPC users are on the Windows platform (67.7% as of January 2026), it could be argued that no effort for Linux Desktop (4.02%) support is justified.

what do the Lazarus developers think?

I have to back up PascalDragon.

Even if someone started this fulltime now, it wouldn't be do-able in time.
Even if we ignore the existing design issues in some of that code.

Start with the obvious -> a dual exe must contain WS code for e.g. Gtk2 and QT5 (or 6). At least gtk is afaik hard linked to some gtk libs? So all those calls need to be replaced with LoadLibrary, getting the function pointer and using that.
That is in theory a simple task, a search and replace...
But in real live, if you change that many such calls, there will be somewhere some slight misses. And then you will have lengthy debug sessions. That is, if you spot it. It may affect something that only gets spotted in a few month => that is why there are lengthy RC times, and a fixes branch long before it makes a major release.

Then the WS are tightly bound to the LCL. That is done by the linker. That again needs (best scenario, if it actually is possible) be replaced by runtime connecting.

The WS is exposed in a couple of different ways, they all need to be found. I don't even have a complete list.

Then if you completed that list, and executed it, it all needs to be tested.

And you need to give 3rd parties time to test some such fundamental change.

So, if that was started today, by someone who will spent fulltime (~40 hours a week) on this, and they are really really good, and they deliver a first draft in a few month (awfully optimistic), then that still needs to sit in the main branch for at least another 6 month of testing (if not more). And after that would be branched into a fixes branch, that would have to mature yet another 6 month before release.

Unfortunately, other than that generic insight, I am not very familiar with the various WS for Linux. So I can't say much on what ways there are to go. I have seen talk on it, but I can't judge it much myself. So unfortunately I can't currently contribute to a solution here.

[marcov]

on the other hand, since the vast majority of Lazarus/FPC users are on the Windows platform (67.7% as of January 2026), it could be argued that no effort for Linux Desktop (4.02%) support is justified.

The numbers are even way more skewed if you actually regard binary distribution over distribution borders. That is even a fraction of that number.

[robert rozee]

Even if someone started this fulltime now, it wouldn't be do-able in time.

so instead we do what? just sit back and wait for there to be even less "time"?

assuming the desire is to still ship a Lazarus IDE ELF/Linux binary for AMD64, the alternative is to embrace there being multiple 'sub-versions' of the IDE's binary:

• Lazarus IDE built for GTK2
• Lazarus IDE built for Qt5
• Lazarus IDE built for Qt6

multiply the above list by AMD64, i386, RPi and we now have NINE variants of the ELF file to contend with! and i am sure the list will only get longer. oh, and there is also X11 vs Wayland to contend with. that could take the count up to EIGHTEEN.

or do we abandon GTK2? but as others have pointed out, we are living in 'times of transition', where the is no one widget set that can be assumed as available on all desktop installations. drop GTK2 (as a pre-built Lazarus IDE) in favour of Qt5 and suddenly a whole lot of Linux desktops will be excluded.


cheers,
rob   :-)

[dbannon]

Robert, I cannot see what you are trying to achieve here. While it might be possible, much like cycling across the Simpsom Desert, it would be hard, problem prone work that achieves little.

If you are still trying to soften the blow of losing gtk2, no it would not help. To make and test and debug you will still need gtk2 installed. To use the gtk2 mode, your end users will still need gtk2 installed. And gtk2 is going away.

Testing and debugging would be particularly difficult. My project, tomboy-ng, has about 40 or 50 {$ifdef LCLwidget} Linux directives. And, despite FPC/Lazarus's truly brilliant "write one, compile anywhere" they are mostly necessary. Which would you assert in your model at compile time ?

On the other hand, in my github repo, I make available packages for gtk2, Qt5, Qt6 (and Win32, Cocoa) on various various hardware platforms. Easily built and handled at release time and easily understood by reasonably informed end users.

Sorry, I cannot see the problem you are trying to solve ?

The real issue is that Lazarus Developers need to make a decision about the next default widget set on Linux. The world is waiting on that decision.

Davo

OK, maybe not the whole world but some of us. 

[robert rozee]

Robert, I cannot see what you are trying to achieve here. [...] The real issue is that Lazarus Developers need to make a decision about the next default widget set on Linux. The world is waiting on that decision.

Davo

OK, maybe not the whole world but some of us. 

i lament over the fracturing of Linux distributions. at least with MS Windows a single .exe can still run on every version of Windows that supports the win32 framework - that being from Windows 2000 up to Windows 11. in some cases even as far back as Windows 98SE. i know this because i still use Delphi 5 Professional, released in the year 2000 and running on an XP VM, to successfully generate some packages that run on Windows 11.

the Linux Desktop, on the other hand, has simply fragmented. we have GTK2 vs Qt5 vs Qt6, all mutually incompatible. then we have X11 vs Wayland, with distros wanting to deprecate X11, while Wayland still (according to others) is barely usable. and the list goes on.

i see TWO paths forward in the case of FPC/Lazarus on Linux - either:

• bind in support for everything (as much as is possible) in the one ELF binary, OR,
• distribute the Lazarus IDE package as source-only for the end user to build on their local machine, thereby guaranteeing the IDE and generated applications should be runnable locally

a third option (3.) of switching the distributed ELF binary of the Lazarus IDE to Qt5 or Qt6 only, i see as a disaster. there are now, and will remain for a good few years, too many existing GTK2-only desktops; we are simply stuck having to support GTK2 in one way or another for the foreseeable future.

so i advocate for either of 1. or 2. you prefer 2. that is fine, i'm ok with 2. i'd prefer 1., but 2. is workable. but something needs to be done. because when a user tries to click on the icon for an ELF binary that has unmet dependencies, NOTHING HAPPENS. no feedback, no error message. this is a major failing in the implementation of ALL Linux desktops. this 'just nothing', as if they had expectantly clicked on a blemish on their LCD screen, will result in users (aka "customers") walking away - something we desperately need to avoid at all cost.


cheers,
rob   :-)

[dbannon]

the Linux Desktop, on the other hand, has simply fragmented.

Agreed, its opensource at it best and worst !

we have GTK2 vs Qt5 vs Qt6, all mutually incompatible.

... and gtk3, gtk4 and, probably Qt7. But not mutually incompatible, they can all sit happily beside each other.

X11 vs Wayland,

you missed LibreX, Fred will have a piece of you for that.

• bind in support for everything (as much as is possible) in the one ELF binary, OR,
• distribute the Lazarus IDE package as source-only for the end user to build on their local machine, thereby guaranteeing the IDE and generated applications should be runnable locally

a third option (3.) of switching the distributed ELF binary of the Lazarus IDE to Qt5 or Qt6 only, i see as a disaster.... existing GTK2-only desktops

No, I doubt there more than a few gtk2 only Linux desktops around, even now. Just about ever one will have gtk3 installed, almost all will support Qt5. And, as time goes by, more so. If someone chooses to use a ten year old operating system, they should expect to be limited in their software choices. But sure, the transition would have to be managed ....

you prefer 2. That is fine, i'm ok with 2. i'd prefer 1., but 2. is workable. but something needs to be done. because when a user tries to click on the icon for an ELF binary that has unmet dependencies, NOTHING HAPPENS.

No, I prefer [2] for my use, I feel its not for everyone. But if some work was put into it, made, for example, as seemless as a rebuild of Lazarus when its files are in read-only space, it could work.

gtk3 is not, now, ready. But I wonder if some special effort in that direction could be a better answer. 

No, not "no error msg" if widget set is unavailable, just no GUI msg. And easily fixed. As you have discovered, a linux LCL app can do a whole lot of stuff before it starts the GUI engine. In my app, I read the command line, possibly do some note imports or exports and then check to see if there is already an existing instance running (and take appropriate action). Could be lots of arguments on best way to determine if the right widget set is available and right way to notify user, but do-able IMHO. Just a pascal unit that a programmer could choose to include. Maybe a fun project.

Davo

[robert rozee]

[...]
No, not "no error msg" if widget set is unavailable, just no GUI msg. And easily fixed. As you have discovered, a linux LCL app can do a whole lot of stuff before it starts the GUI engine. In my app, I read the command line, possibly do some note imports or exports and then check to see if there is already an existing instance running (and take appropriate action). Could be lots of arguments on best way to determine if the right widget set is available and right way to notify user, but do-able IMHO. Just a pascal unit that a programmer could choose to include. Maybe a fun project.

Davo

[i'm getting off-topic here]

unfortunately many users are not able to (capable of) launching a terminal window and running a GUI application from it. yes - that way does yield an error message, but trust me - i have tried - for many folks it is well nigh impossible to talk them through starting up a terminal, navigating to the right place where their application resides, then even typing in the "./" followed by the application's name!

what Linux desktops lack is a 'universal' way of popping up a message window on the desktop. zenity does a passable job, but isn't universally available, and i've not found anything else that is. closest is perhaps launching a python script, but then does python have any universally available GUI abilities? or one can launch a terminal window and use that? i've done that before, but it does look extremely 'clunky' and different distros have different names to run a terminal window. or perhaps talk directly to X11 to just create the one error message window?

i am open to suggestions!


btw, is it possible, when using lazbuild to build a project, to specify the widget set to be built against? or is it more complicated than this. i must confess, i have never tried. i've always just stuck with the default of GTK2.


cheers,
rob   :-)

[Thausand]

btw, is it possible, when using lazbuild to build a project, to specify the widget set to be built against? or is it more complicated than this. i must confess, i have never tried. i've always just stuck with the default of GTK2.

wiki https://wiki.freepascal.org/lazbuild

--widgetset=<widgetset> or --ws=<widgetset>
    override the project widgetset. e.g. gtk, gtk2, qt, win32, or carbon.

PS: have you aware MSE (Martin. S. (rip)) and fpGUI (Graeme G.) that not have depend (LCL) widgetset ?

[dbannon]

....
what Linux desktops lack is a 'universal' way of popping up a message window on the desktop. zenity does a passable job,

zenity is easy, its small and all you need do is make it a dependency of your app to ensure its available. It does of course depend on GTK3 but that is going to be on almost all distros for another ten years IMHO.
Libnotify is a touch more elegant and, I think, universally available ? 
There are lots of other alternatives.

btw, is it possible, when using lazbuild to build a project, to specify the widget set to be built against? or is it more complicated than this. i must confess, i have never tried. i've always just stuck with the default of GTK2.

The normal approach is to define, in Lazarus a build mode for each widgtset you support. But you can also do it on the FPC command line defining the appropriate constant. Bit harder to get your link line right but not that hard.

Mode ?  Project->Options->Additions&Overrides.  Add a new build mode for every widget, then, in the grid line them up. Easy to see, hard to describe in words.

Davo

[MarkMLl]

While technically possible does not mean that it's feasible. For the LCL it simply is not worth the effort this would require.

[/quote]

Not relevant. What /is/ relevant is that it would mandate a single set of interface objects with no opportunity for the IDE or programmer to work around them, and irrespective of how much work was put into it most people would find that their programs break.

MarkMLl

[Thaddy]

on the other hand, since the vast majority of Lazarus/FPC users are on the Windows platform (67.7% as of January 2026), it could be argued that no effort for Linux Desktop (4.02%) support is justified.

The numbers are even way more skewed if you actually regard binary distribution over distribution borders. That is even a fraction of that number.

Two things:
1. Linux users prefer to install from their distro's repository. We have no insight in those installs
2. Many Linux users prefer to build from source, either the documented proper way or the convenient fpcupdeluxe way.

Windows users are less likely to use any of thosder two because their eco-system needs adjustments for 1. and 2. feels alien to them.

[robert rozee]

[...] What /is/ relevant is that it would mandate a single set of interface objects with no opportunity for the IDE or programmer to work around them, and irrespective of how much work was put into it most people would find that their programs break

mark: i'm not sure i understand what you mean, can you please explain more?

do you mean that: currently a GUI application built for GTK2 'knows' that it is talking to GTK2 and can tweak things accordingly, likewise one built for Qt5 can do the same. but an application that has been built for both has no means (at the user-code level) of determining if it is talking to GTK2 or Qt5?

or do you mean that programmers building a GUI application that supported both GTK2 and Qt5 would need to put in extra effort to test every aspect of their program against both GTK2 and Qt5?

or do you mean something else?


from what dave wrote:
"Mode ?  Project->Options->Additions&Overrides.  Add a new build mode for every widget, then, in the grid line them up. Easy to see, hard to describe in words."
https://forum.lazarus.freepascal.org/index.php/topic,73405.msg576721.html#msg576721
... it sounds like i should be able to, with just a few clicks, generate ELF binaries for two or more widget sets. i followed his instructions, but unfortunately i get the following error message when compiling in the Lazarus IDE:

Warning: linker: /usr/bin/ld: cannot find -lQt5Pas: No such file or directory
project1.lpr(27,1) Error: Error while linking

... when selecting the 'Qt5' option, and when selecting the 'Qt' option:

Warning: linker: /usr/bin/ld: cannot find -lQt4Pas: No such file or directory
project1.lpr(27,1) Error: Error while linking

the machine that produced the above results is running Linux Mint 22.2 (XFCE) x86-64, supported until April 2029; all my other computers run similar configurations, although the machine i am typing on right now runs a rather old version 19.3.

how do i install Qt5 support? and/or Qt4 support? preferably in a way that does not break anything!

if i can easily produce multiple ELF binaries, each for a different widget set, then i already have available a relatively 'clean' solution to merge these into a single binary than can select between widget sets at startup.


cheers,
rob   :-)

[marcov]

Even if someone started this fulltime now, it wouldn't be do-able in time.

so instead we do what? just sit back and wait for there to be even less "time"?

Do what about what? I assume debian and most other distros will, each in their own time switch to the most promising alternative as default, probably QT5 or 6, as Abou suggested in the above maillist.  IMHO there was a chance on that happening eventually even if the GTK2 deprecation hadn't happened.

We have one binary distribution per distro-version combination now, and that remains so. The only downside is minority architectures and distros might need extra work to package the qt<x>pas package. It is what it is however.

or do we abandon GTK2? but as others have pointed out, we are living in 'times of transition', where the is no one widget set that can be assumed as available on all desktop installations. drop GTK2 (as a pre-built Lazarus IDE) in favour of Qt5 and suddenly a whole lot of Linux desktops will be excluded.

Why would those be excluded?  Anyway, as availability of gtk2 in the distros winds down, probably so will interest to continue develop and ship Lazarus with it till it eventually dies. Roughly like GTK1 before it.

From what I heard the real trouble is that GTK3 and later are not so much a logic successor of GTK2 because of two reasons:

• Bug tickets for functionality not stressed for Gnome and the few other core distribution applications were closed randomly by GTK team without resolution.
• The primary Gnome (settings) clients switched to a more web like rendering model to render to fit width, and if height didn't match, show a slider. This invalidates many Lazarus applications more fixed screen orientated widget placement

Those two make that other applications are different from Lazarus, and fixes necessarily for Lazarus somewhat more precise rendering requirements and placing options are not stressed, and the widgetset doesn't advance much in that regard. Some of this probably has to do with HIGHDPI getting more traction, and fixed size screen have a certain font size built in, and I can assume for very widely used applications (like Gnome Settings, but Windows 10+ settings also follow that model) that is better, but for many applications a fixed screen that only caters to a limited range font scaling, fthat is a reasonable assumption and saves a lot of scrolling.

I heard those two issues from multiple sides around the 2013-2016 period, I however don't know in how far that is still the case (and similarly for GTK4, which only just started at the end of that period)

[marcov]

Two things:
1. Linux users prefer to install from their distro's repository. We have no insight in those installs

The subthread was about a Lazarus which dynamically adapts to widgetset. Those most likely would not be in distro's repositories, as it is about circumventing the need for distro specific versions in the first place.

(the multi widgetset dynloaded Lazarus is not very practical wrt cost/benefit IMHO, too much rowing against the stream and thus too much work. But others already pointed that out)

2. Many Linux users prefer to build from source, either the documented proper way or the convenient fpcupdeluxe way.

And those also wouldn't use custom multi widget pre built binaries, so both arguments wouldn't change the number of users left over to run such downloaded universal Lazarus ELF binary, even if Robert's numbers were wrong.

So I don't know why you reply to me. Maybe you meant to reply to Robert's original statement?

[PascalDragon]

While technically possible does not mean that it's feasible. For the LCL it simply is not worth the effort this would require.

PascalDragon: are you also one of the Lazarus developers? i thought you were on 'team FPC'.

Being “Team FPC” does not mean that I never worked inside the LCL. I have hunted the one or other issue inside it and thus I have a rough overview how it is structured internally.

assuming the desire is to still ship a Lazarus IDE ELF/Linux binary for AMD64, the alternative is to embrace there being multiple 'sub-versions' of the IDE's binary:

• Lazarus IDE built for GTK2
• Lazarus IDE built for Qt5
• Lazarus IDE built for Qt6

The Debian packages are generated by the Debian package maintainer from source so it would be absolutely no problem for them to generate the IDE in a Qt variant if they'd be willing.