Fedora 39 Native File Chooser issues when compiled on RH8.9.1

[Gonzalo Garramulo]

This is a minor issue.

A user of my program ran into a Linux issue on Fedora 39 that I don't know how to resolve.

I compile my application on Rocky Linux 8.9.1 and distribute most (non-system) libraries with it, including libpango and libpango-cairo, based on what ldd reports as dependencies (recursively).

My application works fine on RL8.9.1 and Ubuntu 22.04.3 LTS, after doing:

sudo apt reinstall libgdk-pixbuf2.0-0

But, my user reported a crash on Fedora 39 when accessing the Native File Chooser, instead of my custom file chooser.  He gets the following warnings and error:

Gtk-Message: 23:19:51.272: Failed to load module "xapp-gtk3-module"
/usr/lib64/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib64/gio/modules/libgvfsdbus.so
/usr/lib64/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib64/gio/modules/libgioremote-volume-monitor.so
/usr/lib64/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib64/gio/modules/libgvfsdbus.so
/usr/lib64/gvfs/libgvfscommon.so: undefined symbol: g_task_set_static_name
Failed to load module: /usr/lib64/gio/modules/libgioremote-volume-monitor.so

(mrv2:7991): Gtk-WARNING **: 23:19:51.318: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
**
Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/Adwaita/scalable/status/image-missing.svg: Unable to load image-loading module: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /usr/lib64/librsvg-2.so.2: undefined symbol: pango_context_set_round_glyph_positions (gdk-pixbuf-error-quark, 5)

To be honest, I am not too familiar with how the Native File Chooser works as I never use it.  Neither libpixbufloader-svg.so, librsvg-2.so nor libgvfscommon.so show as dependencies of either my executable nor the libpango libraries, so I am a tad lost.  I don't distribute neither libpixbufloader-svg nor librsvg-2.

Anybody has ideas?

-- 
Gonzalo Garramuño
ggar...@gmail.com

[Albrecht Schlosser]

On 4/9/24 20:32 Gonzalo Garramulo wrote:
>
> This is a minor issue.
>
> A user of my program ran into a Linux issue on Fedora 39 that I don't
> know how to resolve.
>

> [... error messages elided ...]

>
> To be honest, I am not too familiar with how the Native File Chooser
> works as I never use it.  Neither libpixbufloader-svg.so, librsvg-2.so
> nor libgvfscommon.so show as dependencies of either my executable nor
> the libpango libraries, so I am a tad lost.  I don't distribute
> neither libpixbufloader-svg nor librsvg-2.
>

Only loosely related: do you know `lddtree` for dependency checks?

> Anybody has ideas?
>

FLTK loads the GTK filechooser dynamically if it is found on the system
and if it is not disabled by the user or system option
Fl::option(OPTION_PRINTER_USES_GTK). That's why it doesn't show up in
linked dependencies. Look for 'libgtk' in the FLTK sources, e.g. `git
grep libgtk`. Looks like the library is either "libgtk-3" or
"libgtk-x11-2.0" but this may not help you.

Manolo is our specialist for filechooser related issues and may give you
more details.

[Greg Ercolano]

On 4/9/24 11:32, Gonzalo Garramulo wrote:

Anybody has ideas?

    For what it's worth, in my commercial application which predates the introduction
    of the FNFC (Fltk Native File Chooser), when I added that new capability, I made
    a user preference which allowed the user to control whether the "old" fltk chooser
    would be used, or the native chooser.

    This way if there was any stability problems with the native chooser, the old chooser
    could still be used, as the file chooser is a pretty mission critcal feature in apps that
    use it for File -> Open/Save/etc.

[Albrecht Schlosser]

On 4/9/24 20:49 'Albrecht Schlosser' via fltk.coredev wrote:

FLTK loads the GTK filechooser dynamically if it is found on the system
and if it is not disabled by the user or system option
Fl::option(OPTION_PRINTER_USES_GTK). That's why it doesn't show up in
linked dependencies. Look for 'libgtk' in the FLTK sources, e.g. `git
grep libgtk`. Looks like the library is either "libgtk-3" or
"libgtk-x11-2.0" but this may not help you.

While I wrote about "symbol prefixing" in another post I remembered that the dynamic loading of libgtk was one of the reasons why we introduced "symbol prefixing" in our bundled image libs. It turned out that libgtk depends on a lot of stuff, but particularly on libjpeg and libpng and indirectly on zlib. W/o going into details: this caused crashes when different ABI's were present because symbols (function entry points) were incorrectly resolved. Since the GTK filechooser can show previews of images and some icons...

TL;DR: if there's a chance that your user has any library both FLTK (your image) *and* libgtk depend on and if there may be different versions on your build system and the user's system, then ... see above: ABI mismatch can cause unforeseeable effects.

FYI, on my system we have this very long list of dependencies:

$ lddtree /usr/lib/x86_64-linux-gnu/libgtk-3.so
/usr/lib/x86_64-linux-gnu/libgtk-3.so (interpreter => None)
    libgdk-3.so.0 => /lib/x86_64-linux-gnu/libgdk-3.so.0
        libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.so.0
        libwayland-client.so.0 => /lib/x86_64-linux-gnu/libwayland-client.so.0
            libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8
            libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
        libwayland-cursor.so.0 => /lib/x86_64-linux-gnu/libwayland-cursor.so.0
        libwayland-egl.so.1 => /lib/x86_64-linux-gnu/libwayland-egl.so.1
        libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6
        libXcursor.so.1 => /lib/x86_64-linux-gnu/libXcursor.so.1
            libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1
        libXdamage.so.1 => /lib/x86_64-linux-gnu/libXdamage.so.1
        libXcomposite.so.1 => /lib/x86_64-linux-gnu/libXcomposite.so.1
        libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2
        libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1
    libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0
    libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0
    libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
        libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1
            libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1
            ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
    libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0
    libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.0.so.0
        libthai.so.0 => /lib/x86_64-linux-gnu/libthai.so.0
            libdatrie.so.1 => /lib/x86_64-linux-gnu/libdatrie.so.1
    libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0
        libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6
            libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16
            libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1
                libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1
        libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3
    libcairo.so.2 => /lib/x86_64-linux-gnu/libcairo.so.2
        libpixman-1.so.0 => /lib/x86_64-linux-gnu/libpixman-1.so.0
        libxcb-shm.so.0 => /lib/x86_64-linux-gnu/libxcb-shm.so.0
        libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1
            libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6
            libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6
                libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0
                    libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0
        libxcb-render.so.0 => /lib/x86_64-linux-gnu/libxcb-render.so.0
    libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0
    libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
    libfribidi.so.0 => /lib/x86_64-linux-gnu/libfribidi.so.0
    libcairo-gobject.so.2 => /lib/x86_64-linux-gnu/libcairo-gobject.so.2
    libgdk_pixbuf-2.0.so.0 => /lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
        libjpeg.so.62 => /lib/x86_64-linux-gnu/libjpeg.so.62
    libatk-1.0.so.0 => /lib/x86_64-linux-gnu/libatk-1.0.so.0
    libepoxy.so.0 => /lib/x86_64-linux-gnu/libepoxy.so.0
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
    libXi.so.6 => /lib/x86_64-linux-gnu/libXi.so.6
    libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6
    libatk-bridge-2.0.so.0 => /lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0
        libatspi.so.0 => /lib/x86_64-linux-gnu/libatspi.so.0
        libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3
            libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0
                libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2
                libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20
                    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
                liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5
                libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1
                liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1
    libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

Good luck!

[Albrecht Schlosser]

On 4/9/24 21:15 Greg Ercolano wrote:
>
>     For what it's worth, in my commercial application which predates
> the introduction
>     of the FNFC (Fltk Native File Chooser), when I added that new
> capability, I made
>     a user preference which allowed the user to control whether the
> "old" fltk chooser
>     would be used, or the native chooser.
>
>     This way if there was any stability problems with the native
> chooser, the old chooser
>     could still be used, as the file chooser is a pretty mission
> critcal feature in apps that
>     use it for File -> Open/Save/etc.
>

Yup, see FLTK's Fl::option(OPTION_PRINTER_USES_GTK) which the user can
disable (OFF) either for them or system-wide with fltk-options, or the
program can set it in main().

Obvious drawback: as the option name implies (not literally, but anyway)
this disables loading the GTK filechooser which is not optimal but
should prevent the crash if that's the cause.

[Manolo]

Le mardi 9 avril 2024 à 21:22:52 UTC+2, Albrecht-S a écrit :

Yup, see FLTK's Fl::option(OPTION_PRINTER_USES_GTK) which the user can
disable (OFF) either for them or system-wide with fltk-options, or the
program can set it in main().

That's not the relevant option.  OPTION_PRINTER_USES_GTK deals with the printer chooser, not the file chooser.

Consider OPTION_FNFC_USES_GTK instead.

Consider also OPTION_FNFC_USES_ZENITY because the native file chooser now uses the zenity file chooser if it's available, otherwise it uses the GTK file chooser by opening dynamically libgtk-3.so if found. If none of that is found, it uses the FLTK file chooser.

I've run here FLTK's native file chooser under Fedora39 and see it runs OK both with and without zenity.

Your user should make sure libgtk-3.so is installed properly on the running fedora system. That should be enough for an FLTK client app to run the native file chooser.

[Manolo]

Here is an experiment I just made here:

1) build test/native-filechooser on Debian 12

2) copy the resulting executable file to Fedora39

3) run the copied native-filechooser under Fedora: the GTK file chooser runs OK.

[Bill Spitzak]

I don't think any system that does not use fork+exec to run the native file chooser should be attempted.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/2e472c79-11c0-45d7-95ae-9f4791eaeb52n%40googlegroups.com.

[Gonzalo Garramulo]

El 10/4/24 a las 04:10, Manolo escribió:

> Here is an experiment I just made here:
> 1) build test/native-filechooser on Debian 12

Debian 12 is still not an option, as I still have to remain backwards
compatible with RH8.  Also, I need to build a shared FLTK.  And... I
cannot use a Docker container to build my application anymore as I have
a dependency on a proprietary library.

--
Gonzalo Garramuño
ggar...@gmail.com

[Gonzalo Garramulo]

El 9/4/24 a las 16:15, Greg Ercolano escribió:

>
> On 4/9/24 11:32, Gonzalo Garramulo wrote:
>
>> Anybody has ideas?
>>
>     For what it's worth, in my commercial application which predates
> the introduction
>     of the FNFC (Fltk Native File Chooser), when I added that new
> capability, I made
>     a user preference which allowed the user to control whether the
> "old" fltk chooser
>     would be used, or the native chooser.
>

I have that too in mrv2.  The default file requester on Linux is a
modified and bug fixed version of the Flu file requester, which I love. 
But... artists that look at it don't like it since it looks ugly and
unfamiliar and prefer the native file requester.

Artists on Windows, they don't even use a file requester.  They just
drag files from File Explorer.

Also, on macOS, my custom file chooser would have problems accessing the
private user directories due to Gatekeeper preventing my non-notarized
application.

I am still looking for a better file requester, so if anyone has an
idea, I am all ears.

--
Gonzalo Garramuño
ggar...@gmail.com