Debian trixie upgrade FLTK or not?

[Andre Steenveld]

Hi all,

As reported in another thread I would give feedback on updating FLTK v1.4.3 to FLTK v1.4.4 on Debian Trixie.

I have Debian running as a virtual machine and as preperation I made a snapshot.

Just in case and it does not take much time.

The I had a look on reverse dependencies of FLTK-1.4 and the list is quite long!

My guess is that this is different on each system so it makes no sense to copy the list here.

If a uninstall of FLTK-1.4.3 also involves uninsalling all packages depending on it then I will end up having a system with a big hole in it.

My guess is that installing FLTK-1.4.4 will not automatic reintroduce all the uninstalled.

An my experience with *nix in general and more specific Debian trixie is to rusty and scattered to thrust myself in pulling this off.

Running FLTK-1.4.3 and FLTK-1.4.4 is not advised to do.

Unless there is an easy way to do `sudo apt update FLTK-1.4.4` from a local build I'm not ready to go to uninstall and reinstall FLTK.

I opt for the workaround of @Albrecht-S and stick to FLTK-1.4.3

Sorry, not much of a worthy feedback but this is how it is for the occasional *nix user.

 

[Albrecht Schlosser]

On 1/13/26 16:05 Andre Steenveld wrote:
> Hi all,
>
> As reported in another thread I would give feedback on updating FLTK
> v1.4.3 to FLTK v1.4.4 on Debian Trixie.

> ...
> ... I had a look on reverse dependencies of FLTK-1.4 and the list is

> quite long!
> My guess is that this is different on each system so it makes no sense
> to copy the list here.

This depends on how you looked at the reverse dependencies. AFAICT `apt`
or `apt-get` etc. list all potential packages but this doesn't mean that
any of them are installed on your system.

> If a uninstall of FLTK-1.4.3 also involves uninstalling all packages

> depending on it then I will end up having a system with a big hole in it.

Yes, if you (try to) uninstall FLTK-1.4.3 (the runtime package) then all
packages depending on it would also be removed. However, `apt` lists
these packages before removal and gives you a choice to do it or not.

> My guess is that installing FLTK-1.4.4 will not automatic reintroduce
> all the uninstalled.

That's correct. Furthermore there's currently no Debian package with
FLTK 1.4.4 that you could install. You would have to build FLTK 1.4.4
(and optionally all dependent packages) yourself.

> Running FLTK-1.4.3 and FLTK-1.4.4 is not advised to do.

"Not advised" means in other words: It's hard to tell what happens on a
particular system if you have a system package with 1.4.3 installed in
default system paths and build your own 1.4.4, but theoretically it's
possible to have system app packages that depend on 1.4.3 and then build
your own app(s) with FLTK 1.4.4, 1.4.5, or even 1.5.0 (git master).

> Unless there is an easy way to do `sudo apt update FLTK-1.4.4` from a
> local build I'm not ready to go to uninstall and reinstall FLTK.

OK, (again: theoretically) it's possible to upgrade the FLTK runtime
(shared) libraries to a higher version like 1.4.5, and since FLTK
guarantees binary (ABI) compatibility all applications linked against
the 1.4.3 runtime would continue to work with 1.4.4 or 1.4.5 or higher
(but not 1.5.x !). This is what (Linux) distro managers are supposed to
do: upgrade the FLTK shared libraries w/o having to rebuild all
applications. But don't try this yourself, you'd have to build the
higher version with the same compiler setup as the older one.

There are chances that 1.4.4 (or 1.4.5) will be available in the Trixie
"backports" repository (if the Debian/FLTK maintainer opts to do this).
Currently 1.4.4 is in Testing aka Forky and would be a candidate for a
backport. However, I just checked the backports repo of my Trixie VM and
there's no FLTK 1.4.x available (you could also check the online package
list).
https://backports.debian.org/Instructions/

During the next days / weeks (maybe two months?) my plan is to fix some
outstanding issues and to release 1.4.5 which would be a candidate for
Debian Unstable -> Testing -> Trixie-Backports. If the Debian maintainer
agrees, then I think, this would be a way to fix the FLTK config issues
in Trixie. Otherwise it's possible that a patched version 1.4.3-xyz will
be installed at any time but I don't know enough about Debian policies
to tell if this is doable.

> I opt for the workaround of @Albrecht-S and stick to FLTK-1.4.3

Yes, that's a good plan if you want to stick with original Debian FLTK
packages.

> Sorry, not much of a worthy feedback but this is how it is for the
> occasional *nix user.

Every feedback is appreciated, and at least you gave us feedback, no
matter what you found out for yourself. Thank you very much.

[Albrecht Schlosser]

On 1/14/26 00:31 'Albrecht Schlosser' wrote:

if you (try to) uninstall FLTK-1.4.3 (the runtime package) then all packages depending on it would also be removed. However, `apt` lists these packages before removal and gives you a choice to do it or not.

From my Trixie VM:

# apt remove libfltk1.4
The following package was automatically installed and is no longer required:
  fltk1.4-doc
Use 'apt autoremove' to remove it.

REMOVING:
  fltk-options  fltk1.4-games  fluid  libfltk-cairo1.4  libfltk-forms1.4  libfltk-gl1.4
  libfltk-images1.4  libfltk1.4  libfltk1.4-dev

Summary:
  Upgrading: 0, Installing: 0, Removing: 9, Not Upgrading: 0
  Freed space: 9,970 kB

Continue? [Y/n] n
Abort.

Don't miss to type 'n' or 'N', the default is 'Y' (if you try yourself) !

In my case only the pure FLTK packages would be removed because I never installed any applications that depend on FLTK.

[Andre Steenveld]

Op woensdag 14 januari 2026 om 00:40:39 UTC+1 schreef Albrecht-S:

On 1/14/26 00:31 'Albrecht Schlosser' wrote:

if you (try to) uninstall FLTK-1.4.3 (the runtime package) then all packages depending on it would also be removed. However, `apt` lists these packages before removal and gives you a choice to do it or not.

From my Trixie VM:
# apt remove libfltk1.4 The following package was automatically installed and is no longer required: fltk1.4-doc Use 'apt autoremove' to remove it. REMOVING: fltk-options fltk1.4-games fluid libfltk-cairo1.4 libfltk-forms1.4 libfltk-gl1.4 libfltk-images1.4 libfltk1.4 libfltk1.4-dev Summary: Upgrading: 0, Installing: 0, Removing: 9, Not Upgrading: 0 Freed space: 9,970 kB Continue? [Y/n] n Abort.

I got a very similar result.

andre@debian:~/development/BurrTools/AppBuild/source$ sudo apt remove libfltk1.4

The following package was automatically installed and is no longer required:
  fltk1.4-doc

Use 'sudo apt autoremove' to remove it.

REMOVING:
  fltk-options  fltk1.4-games  fluid  libfltk-cairo1.4  libfltk-forms1.4  libfltk-gl1.4  libfltk-images1.4  libfltk1.4  libfltk1.4-dev

Summary:
  Upgrading: 0, Installing: 0, Removing: 9, Not Upgrading: 0
  Freed space: 9,970 kB

Continue? [Y/n] n
Abort.

Yesterday I did some testing and building, all without problems. No direct need for an upgrade.

The safer option, less hassle, for me is to wait for a backport to become available.

Thanks again for your advise. :-)

[Ian MacArthur]

For what it may be worth (probably not much...) I'd not bother trying to update the system-FLTK on debian right now. (Or Ubuntu for that matter. Or any RH derived distro, or...)

I always build a "user" version of FLTK and use that in my builds instead. Which is fine - needs a bit of fiddling about in setting up the build to ensure it doesn't "accidentally" pull in the system libs, but otherwise that seems to be the "best" option.

[Andre Steenveld]

Op woensdag 14 januari 2026 om 16:30:52 UTC+1 schreef Ian MacArthur:

For what it may be worth (probably not much...) I'd not bother trying to update the system-FLTK on debian right now. (Or Ubuntu for that matter. Or any RH derived distro, or...)

I always build a "user" version of FLTK and use that in my builds instead. Which is fine - needs a bit of fiddling about in setting up the build to ensure it doesn't "accidentally" pull in the system libs, but otherwise that seems to be the "best" option.

It is not advised to have two versions of FLTK side to side, repeated warning several times in this group. And as an unexperienced user I can only stick to that (or else...)

The testing I did yesterday was with v1.4.3 installed but using the self build v1.4.4 copy. All the warnings I have seen say that whith such minor differences in versions there sould not be to many problems and I did see (better to say did not recognise) none of it. But what when I want to test with v1.5.x?

Uninstall v1.4.3 is not such a big thing as I thought it to be so it might be worth doing it to avoid risks. 

What you say contradicts what is advised and for me that is a bit confusing. Just one question. Do you uninstall the system version?

[Greg Ercolano]

It is not advised to have two versions of FLTK side to side, repeated warning several times in this group. And as an unexperienced user I can only stick to that (or else...)

What you say contradicts what is advised and for me that is a bit confusing. Just one question.

    Hmm, I think there's some confusion about the "-dev" vs "non-dev" debian packages.

        > Leave the system "libfltkx.x" package in place, never remove that, as debian's own tools that use fltk need the runtime binaries that package provides.

        > Only uninstall (i.e. remove) the system libfltkx.x-dev package (emphasis on the "-dev" suffix) as that will break builds of newer fltk library source code versions pulled from github or fltk.org, due to interference that package causes with the /usr/include/FL directory. (see below)

    Long answer:

    If one is going to build the latest versions of fltk from github or fltk.org snapshots, then be sure the debian "-dev" package is removed first (if it was ever installed to begin with) to remove any interference it might cause with downloaded fltk library source code builds.

    The only reason to use the debian "-dev" version of FLTK is if you're recompiling debian tools, and want the same version of FLTK that debian tools used when your version of debian was constructed.

    On my Ubuntu 24.x that package is called "libfltk1.3-dev", and I never install it, because I'm never rebuilding debian tools, and always using the latest versions of FLTK for my own tools. So a good reason to uninstall that package is if you plan to download recent versions of the FLTK library (github or fltk.org tarball snapshots), and dont want interference from the /usr/include/FL/ directory that package creates. This is because the C++ compiler will try to pull in that /usr/include/FL directory first when building a newer version of the fltk lib, and that interference causes weird errors and crashes, due to the different headers.

    Most people building their own FLTK apps want to use recent versions of FLTK downloaded from github or fltk.org, and don't want interference caused by the debian provided older source code include files provided by that "-dev" package. Debian tools that use fltk don't need the "-dev" package just to run.

 So don't install the "-dev" fltk package if you want to use newer fltk source code builds.

 What you would leave in place (untouched) would be the debian installed fltk runtime libs/dll's that debian's own tools that use fltk .dll's to run. Uninstalling that package will remove all those debian tools as dependencies, which makes a mess!

   On my Ubunti 24.x that binary install of fltk's libs is called "libfltk1.3t64" (without the -dev suffix). Definitely don't uninstall that, or you'll break debian tools that use fltk's .dll's at runtime.

 Do you uninstall the system version?

    I'm pretty sure the consensus is to uninstall only the "-dev" package (e.g. "libfltk1.3-dev" in my case), but leave the other fltk (non-dev)  packages alone.

[Ian MacArthur]

On Wednesday, 14 January 2026 at 18:57:51 UTC Andre wrote:

It is not advised to have two versions of FLTK side to side, repeated warning several times in this group. And as an unexperienced user I can only stick to that (or else...)

Umm, I'm not sure that _is_ the advice: it is certainly not the advice I give.

It is not a good idea to try and _install_ more than one version of FLTK. But FLTK is _by design_ able to be used from a local build folder and never needs to be installed at all to be usable.

So, let's see... OK, on this machine I currently have 6 versions of FLTK, oops, no 7, forgot one... So long as you can control the include paths used by your build (to ensure the local path is found before the system path) that works flawlessly.

 

What you say contradicts what is advised and for me that is a bit confusing. Just one question. Do you uninstall the system version?

No, I just leave it in place. I don't think there are many things on the Ubuntu that I typically use that really _depend_ on the FLTK runtime but I'm never quite sure so I just leave it alone! (I know Mike's printer control stuff for CUPS used to use FLTK runtime binaries, but IIRC they were static linked anyway so... Beyond that, I don't know what system apps might want FLTK shared libs, but I guess not many, so maybe the "system" doesn't care whether FLTK is installed or not!)

Also, as Greg points out, it is often not the "binary" part of a system FLTK install that is problematic usually - it is the API part (the include files and so forth) that typically come from the distro's -dev packages. 

FWIW, if the system install is 1.4.3, and you build 1.4.4 locally then it probably does not much matter if your subsequent builds use the 1.4.3 FL include files from the system, since 1.4.3 and 1.4.4 expose the same API.

[Andre Steenveld]

The details you give are clear enough for me.

I do not install the version(s) I build and I build in different locations so I should be safe.

Then I stick to what I'm doing now and keep v1.4.3 where it is.

Making good progress in learing how to use FLTK on Debian and Win32.

Again, thanks for the advise and the clarifications.

Much appreciated. :-)

[Albrecht Schlosser]

On 1/15/26 14:37 Andre Steenveld wrote:
> The details you give are clear enough for me.
> I do not install the version(s) I build and I build in different
> locations so I should be safe.

I'm sorry if my advice contributed to your confusion because it was
oversimplified. It's easier to say "remove (all of) FLTK 1.4.3" than to
make clear which packages should be removed. I agree with Ian and Greg
that removing the '-dev' package should suffice to avoid conflicts.

> Then I stick to what I'm doing now and keep v1.4.3 where it is.
> Making good progress in learing how to use FLTK on Debian and Win32.

That's good to read. Have fun with FLTK!

Just a bit of history: when I looked for a GUI for our text oriented
commercial application around 2001 I found FLTK and used it because we
needed something for a client/server architecture where the client would
create the widgets dynamically at runtime, controlled by input from the
server. FLTK was simple enough (w/o such overhead as Qt etc.) and
allowed to do what we needed. That's why I use FLTK now for about 25
years and contribute to its steady development.