tip-toeing into the future of linux package management — flatpak

Ever since I started to work with Linux back in the early 1990s, package management was always an important issue, and a number of times, a big hassle. Over the years the various package managers sorted themselves out and consolidate so that the two major ones were deb for Debian based distributions and rpm for Redhat, SuSE, and other distributions that adopted the RPM package management system. The problem, however, is that all the distributions don’t always install the latest major packages.

If you want the latest  you usually pick a bleeding-edge distribution such as Fedora, with the guarantee that as long as you stay with the latest Fedora release you’re guaranteed the latest or very near-latest. Other distributions, such as Linux Mint 21.1, will ship with what the upstream distribution, which is Ubuntu 22.04, shipped with. Case in point is LibreOffice. Linux Mint 21 shipped with LibreOffice version 7.2. The problem with this is two-fold; the current release of LibreOffice is 7.5, and the LibreOffice developers have advised everyone to step up to 7.5, especially if you have 7.4 or earlier. The Linux Mint maintainers won’t do that, and I have no desire to add yet another PPA in order to get the latest LibreOffice version.

To solve this version mismatch I uninstalled everything involved in the original LibreOffice installation, then installed the flatpak package version of LibreOffice. Once installed I opened it and checked the version.

Sure enough I had the latest version, with all the new features and bug fixes. You’ll note that LibreOffice for personal use is now called LibreOffice Community, the version being distributed for free non-commercial (i.e. not within a business) use. LibreOffice has a link ( https://www.libreoffice.org/download/libreoffice-in-business/ ) for businesses wanting to use LibreOffice, calling it LibreOffice Enterprise. I think it’s a great idea.

Once installed I performed a quick check and discovered I’d lost nothing as far as functionality is concerned. All the individual applications are still in the flatpak, and from what I can tell all the functionality within the applications I am most interested in using (Writer, Calc (spreadsheet) and Impress (presentation)) are still fully functional.

While each individual LibreOffice application is broken out and available as such in the menu, I prefer to just start the overall LibreOffice application and then start from there. It’s just a nice way to keep everything organized.


I’ve been using LibreOffice for some time now, and I have to admit that this is the best looking, best polished version yet. Having the application in a flatpak means I can keep up with the current version, regardless of what version of Linux Mint I use. Because of the way LibreOffice flatpak has worked, I’m looking for flatpak versions of a number of other applications that are installed via apt, and replacing those to keep up with the latest.

solving a clang++ compiler problem on linux mint 22.1

During my initial setup of Linux Mint on the Samsung Series 7, I installed the Flutter toolkit ( https://docs.flutter.dev/get-started/install/linux ). Flutter has additional application requirements, one of which is Clang. So I installed all the additional requirements, then installed Visual Studio Code, then within VSCode I installed Flutter plugin.

Note that I did not install support for Android (Android SDK and Android Studio) nor the Web (via Chrome). All I’m doing is writing Flutter desktop applications.

The Flutter plugin within VSCode automates quite a lot. Using the VSCode Command Palette, you can create an initial Flutter application (Flutter: New Project) that will create skeleton code and build files that compiles and runs the graphical equivalent of hello, world.

Visual Studio Code with the Flutter plugin and an initial Flutter application, running that application in debug mode.

As you can see, the Flutter tools for both the framework and the VSCode plugin provide an effortless on-ramp to developing applications. Creating the start of an application is ridiculously easy, and it’s capable of building and executing from the get-go. One feature this has and I use quite a lot is hot reload. When I make changes to the code, when I save the changes they’re rebuilt and the running application restarted immediately showing those changes. That’s why I use this setup.

Sample Flutter application running on the desktop.

And here is the initial application’s extremely simple desktop window. When this works well, it’s a little like magic.

Unfortunately I ran into a problem where Clang, one of Flutter’s dependencies, could not link a C++ application that is part of the Flutter application. The error message reported by the Flutter tooling was (with much superfluous reporting snipped away):

.../usr/bin/ld: cannot find -lstdc++: No such file or directory...

This really annoyed me because I have this same setup on my other Linux Mint system, the UM250. With a bit of googling I discovered what was wrong, and how I’d accidentally side-stepped the issue on the UM250. I solved the problem on the Series 7 with sudo apt install libstdc++-12-dev. After that the Flutter tool chain just worked.

Why didn’t I see this issue on the UM250? Because I’d installed gcc/g++ version 12 to support another small project I was working on. On the UM250 I have both versions 11 and 12. Then when I later updated an older installation of Flutter and ran the same simple tests, everything worked there as well. I don’t intend to install gcc/g++ version 12 on the Series 7 as there is no need.

What I don’t understand is how Clang and GCC got out of sync on Linux Mint 22.1. The version of Clang installed is version 14, and requires libstdc++-12. Unfortunately Linux Mint 22.1 installs GCC version 11, which means that if you wanted to build with Clang you’re out of luck unless you know of Clang 14’s dependencies.