FLTK on RHEL 9

[Rob McDonald]

I'm trying to build FLTK 1.4.0 (close to the tip of the branch) on RHEL 9.  This is a Wayland machine, and I'm trying to avoid installing X11 libraries and dependencies.

I can't sort out which packages I need to have installed to get FLTK to build.  Here is the current output from CMake configuring FLTK.

-- Checking for module 'wayland-client>=1.18'
--   Found wayland-client, version 1.21.0
-- Checking for module 'wayland-cursor'
--   Found wayland-cursor, version 1.21.0
-- Checking for module 'wayland-protocols>=1.15'
--   Found wayland-protocols, version 1.31
-- Checking for module 'xkbcommon'
--   Found xkbcommon, version 1.0.3
-- Could NOT find X11 (missing: X11_X11_INCLUDE_PATH X11_X11_LIB)
-- Warning: system libdecor doesn't satisfy version >= 0.2.0,
--          using bundled libdecor library instead.
-- Checking for module 'wayland-egl'
--   Found wayland-egl, version 18.1.0
-- Checking for module 'egl'
--   Package 'egl', required by 'virtual:world', not found
-- Checking for module 'gl'
--   Package 'gl', required by 'virtual:world', not found
-- Modules 'wayland-egl, egl, and gl' are required to build for the Wayland backend.

CMake Error at CMake/options.cmake:607 (message):
  *** Aborting ***
Call Stack (most recent call first):
  CMakeLists.txt:78 (include)

I've installed wayland-egl, but there are no egl and gl packages that jump out at me.  When I search for 'egl', most of the packages I haven't installed end up with X11 dependencies and therefore want to pull in the entire known universe.

Does anyone know what packages I need to build FLTK on Wayland on RHEL?

Thanks,

Rob

[Rob McDonald]

I ended up making some progress by installing 'libglvnd-devel'.  This provides egl.h and gl.h -- but it also pulls in a bunch of X11 stuff (which is why I had avoided it previously).

I am now trying to build with:

-DFLTK_BACKEND_WAYLAND=ON

-DFLTK_BACKEND_X11=OFF

But CMake is still searching for (and finding) X11, it then searches for a bunch of X11 related packages that I don't have installed.

libxfixes-dev

libxrender-dev

libxft-dev

libxcursor-dev

libxinerama-dev

In my opinion, with X11=OFF, FLTK's CMake should not proceed to search for a bunch of X11 related dependencies.

Are these really required for something, or are they just leftovers in the grand CMake and Wayland transition?

Rob

 

[Rob McDonald]

I went ahead and installed them and am making progress.

FLTK's CMake recommends libgtk3-dev as well -- which has a large number of X11 related dependencies.  So perhaps it just isn't possible to work on a Wayland-only system.

It would be nice if the FLTK CMake would echo back configuration options at the start of the process -- that way, a user can verify that things got set as expected.  There is a nice summary on CMake's conclusion, but that isn't helpful if CMake crashes / quits before it gets there (fails to find a required package, etc).

Further, the summary output on CMake's conclusion includes a line about 'Use Wayland' -- but it does not say anything about X11.  I see no way to confirm if I've successfully disabled X11 in this build.  The 'Use Wayland' simply says (if available at run-time), which makes me think I have failed to disable X11...

Rob

 

[Manolo]

Please, git pull to last source code of FLTK and run CMake with these options

-DFLTK_BACKEND_X11=0   -DFLTK_USE_SYSTEM_LIBDECOR=0   -DFLTK_USE_LIBDECOR_GTK=0

You should be able to build FLTK without X11 libraries.

The CMake summary will also make clear that X11 will not be used.

[Rob McDonald]

Thanks Manolo

 

[Rob McDonald]

This may be technically off topic, but it is for an on-topic purpose...

Is there a command (like ldd) that will tell me what dynamic libraries a static library pulls in?

I believe I've succeeded in getting FLTK to use only Wayland stuff on this RHEL9 machine.  However, when I run

ldd ./myapp

I get a huge list of libraries -- that clearly include X11 stuff.  I'd like to figure out who is pulling it in -- perhaps it is FLTK, or maybe GLEW, or maybe something else...

Since FLTK is statically linked, I'd like to check what dynamic libraries it pulls in itself.  However...

ldd ./libfltk.a

ldd: warning: you do not have execution permission for `./libfltk.a'

        not a dynamic executable

Which generally makes sense.

Is there an equivalent to 'ldd' on Linux for *.a files?  How about for *.so files?

Rob

[Albrecht Schlosser]

On 3/14/24 01:27 Rob McDonald wrote:

This may be technically off topic, but it is for an on-topic purpose...

Is there a command (like ldd) that will tell me what dynamic libraries a static library pulls in?

I believe I've succeeded in getting FLTK to use only Wayland stuff on this RHEL9 machine.  However, when I run

ldd ./myapp

I get a huge list of libraries -- that clearly include X11 stuff.  I'd like to figure out who is pulling it in -- perhaps it is FLTK, or maybe GLEW, or maybe something else...

Is there an equivalent to 'ldd' on Linux for *.a files?

Not one I'm aware of, and it really wouldn't make much sense. I know that 'nm' can list all "symbols" involved in a static lib but I doubt that this would lead you anywhere.

How about for *.so files?

Sure, that works. Basically you could use every listed .so file recursively but I recommend `lddtree` which does this for you, like this:

$ lddtree lib/libfltk.so
lib/libfltk.so (interpreter => None)
    libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6
        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
    libXinerama.so.1 => /lib/x86_64-linux-gnu/libXinerama.so.1
        libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6
    libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3
...

Of course you can use lddtree on your executable as well.

On Debian (and likely Ubuntu as well) this is in package 'pax-utils'. HTH.

[Greg Ercolano]

On 3/13/24 17:27, Rob McDonald wrote:

This may be technically off topic, but it is for an on-topic purpose...

Is there a command (like ldd) that will tell me what dynamic libraries a static library pulls in?

    Hmm, I think that might be a trick question.

    AFAIK, technically static libs don't reference other libraries, there's just .o files
    that haven't been linked yet, so they don't hold any info about how to find external
    references.. that happens during linking, e.g. when a binary is being created.

    At the link stage you get to choose how external libs are resolved, by either referring
    to static or dynamic libs to resolve them.

[Greg Ercolano]

    For instance, whether libfltk.a references X11 calls, or your app does directly,
    or both, when you link your application, you get to choose if the X11 library
    gets pulled into your app dynamically (-lX11) or statically (/usr/lib64/libX11.a).

    The X11 calls your own app makes are compiled (but not yet linked) into the
    .o files as just external references; subroutine calls with a specific argument list
    with byte sizes. Nothing about where the actual .o files that defines those subroutines
    can be found.

    At link time the subroutine calls in your and fltk's .o files are then resolved,
    and either point to dynamic libs (resolved at run time), or into static .o files
    that are pulled into your binary "statically".
   
    Note that your .o files and/or libfltk.a doesn't say anything about where the
    .o files can be found, it just uses whatever X11 API interface the #include files
    provided during compiling, but not where the actual implementation can be found.
    That info isn't defined until you link the program.

    That's my understanding anyway.. others might have a more precise description
    of how all that works. I sometimes forget the details until I'm forced into working
    at that level. Certainly there's more than "just subroutines", e.g. data as well as
    functions.

[Albrecht Schlosser]

On 3/14/24 01:27 Rob McDonald wrote:

I believe I've succeeded in getting FLTK to use only Wayland stuff on this RHEL9 machine.  However, when I run

ldd ./myapp

I get a huge list of libraries -- that clearly include X11 stuff.  I'd like to figure out who is pulling it in -- perhaps it is FLTK, or maybe GLEW, or maybe something else...

Our Wayland build uses libcairo for drawing, and the shared Cairo lib is linked to several X11 libs (which is expected). On my Debian system:

$ lddtree /lib/x86_64-linux-gnu/libcairo.so.2
/lib/x86_64-linux-gnu/libcairo.so.2 (interpreter => None)
    libpixman-1.so.0 => /lib/x86_64-linux-gnu/libpixman-1.so.0
        ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
    libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
    libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6
        libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1
            libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1
    libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16
    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
    libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1
    libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6
    libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

I suggest that you try to find out if this is the case on your system as well. If this is the case then libcairo.so pulls in the X11 dependencies.

The only way I can think of to avoid this would be to link to libcairo statically. On my (Debian) system I find /usr/lib/x86_64-linux-gnu/libcairo.a, hence it might be possible (technically) but I don't know how to go further from that.

Is it worth the effort? Probably not. On Debian you can use `apt show libcairo2` and this reveals:

Package: libcairo2
Version: 1.16.0-7
Priority: optional
Section: libs
Source: cairo
Maintainer: Debian GNOME Maintainers <pkg-gnome-...@lists.alioth.debian.org>
Installed-Size: 1,338 kB
Depends: libc6 (>= 2.35), libfontconfig1 (>= 2.12.6), libfreetype6 (>= 2.9.1),
         libpixman-1-0 (>= 0.30.0), libpng16-16 (>= 1.6.2-1),
         libx11-6, libxcb-render0, libxcb-shm0, libxcb1 (>= 1.6), libxext6, libxrender1,
         zlib1g (>= 1:1.1.4)
...

This may be different on your system but I'm afraid that it would be difficult to link all required libs statically w/o having to link X11 libs if that is possible at all. Note that you would have to link libfltk.so statically with libcairo in the first place etc. etc.

What do you want to achieve? Do you want to build an executable that can be deployed to other (similar) systems that don't have X11 libs installed? Is this a security issue?

[Greg Ercolano]

On 3/13/24 19:22, 'Albrecht Schlosser' via fltk.general wrote:

...

What do you want to achieve? Do you want to build an executable that can be deployed to other (similar) systems that don't have X11 libs installed? Is this a security issue?

    Just a guess: he's probably deploying binaries to customers, and wants to minimize runtime dynamic link errors by trying to pull as many libs in statically as possible.

    Nothing worse than a customer who has to struggle with "libxxx.so: not found" errors, and the developer having to try to figure out what distro the end user is using, and which "yum/apt install libxyz" commands are needed to get them running.

[Rob McDonald]

Thanks -- that helps.

I guess I had assumed there was some meta-data dragged along that listed dependencies.  In reality, it just complains in the end if there is anything it needs that you haven't provided.

Fair enough.

Rob

 

[Rob McDonald]

Thanks, this is helpful and points at Cairo as the likely culprit for the unexpected dependencies.

I need to build my program for computers that have notoriously stingy sys admins.  I don't have a list of pre-installed packages, but I can generally assume that the package list is minimal.

My users do not have sudo access -- or really even the ability to ask admins to add additional packages.  These computers are air-gapped from the internet.  I do not have access to one of these, so I'm building / testing on a local VM (that I do have sudo access to) and will be sending them a package to test on their machines.

RHEL9 (thank goodness, they're finally updating from RHEL7) is primarily a Wayland platform.  If the machine is a Wayland machine, I struggle to see why a bunch of X11 libraries would be installed.

I'm approaching this from a perspective of minimizing external dependencies -- statically link everything I can -- don't have a bunch of crud that isn't really needed.

Rob

 

[Albrecht Schlosser]

On 3/14/24 03:46 Rob McDonald wrote:

I need to build my program for computers that have notoriously stingy sys admins.  I don't have a list of pre-installed packages, but I can generally assume that the package list is minimal.

OK, I understand.

My users do not have sudo access -- or really even the ability to ask admins to add additional packages.  These computers are air-gapped from the internet.  I do not have access to one of these, so I'm building / testing on a local VM (that I do have sudo access to) and will be sending them a package to test on their machines.

Hmm, that doesn't make life easier.

If the machine is a Wayland machine, I struggle to see why a bunch of X11 libraries would be installed.

Maybe because Wayland or (more likely: other applications) need pango and cairo etc. and therefore the minimal set of X11 libs are also installed.

I'm approaching this from a perspective of minimizing external dependencies -- statically link everything I can -- don't have a bunch of crud that isn't really needed.

OK, I tried to compile and link hello.cxx statically as a Wayland-only app (linked against a Wayland-only libfltk.a) with several statically linked libs. This was an iterative process but I'm showing you the last step. Finally I got it almost working (not really, see below):

g++ -o hello ../../test/hello.cxx `fltk-config --cxxflags` /git/fltk/master/build/debug/lib/libfltk.a \
  -lm -lpthread -L/usr/lib/x86_64-linux-gnu -lpango-1.0 -lgobject-2.0 -lglib-2.0 \
  -lharfbuzz -lwayland-cursor -lwayland-client -lxkbcommon -ldbus-1 -lfontconfig -ldl \
  -lpangocairo-1.0 \
  /usr/lib/x86_64-linux-gnu/libX11.a /usr/lib/x86_64-linux-gnu/libxcb.a /usr/lib/x86_64-linux-gnu/libXau.a \
  /lib/x86_64-linux-gnu/libXdmcp.a /lib/x86_64-linux-gnu/libXcursor.a /lib/x86_64-linux-gnu/libXrender.a \
  /usr/lib/x86_64-linux-gnu/libcairo.a -lfontconfig /usr/lib/x86_64-linux-gnu/libfreetype.a \
  /usr/lib/x86_64-linux-gnu/libpixman-1.a -lpng -lz /usr/lib/x86_64-linux-gnu/libXrender.a \
  /usr/lib/x86_64-linux-gnu/libX11.a /usr/lib/x86_64-linux-gnu/libXext.a /usr/lib/x86_64-linux-gnu/libfreetype.a \
  /usr/lib/x86_64-linux-gnu/libbrotlidec.a /usr/lib/x86_64-linux-gnu/libbrotlicommon.a \
  /usr/lib/x86_64-linux-gnu/libXinerama.a /usr/lib/x86_64-linux-gnu/libXfixes.a

Well, that doesn't look simple, but it's a progress, lddtree shows:

./hello (interpreter => /lib64/ld-linux-x86-64.so.2)
    libpango-1.0.so.0 => /lib/x86_64-linux-gnu/libpango-1.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
        libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0
            libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0
            libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1
                libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1
            libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
        libfribidi.so.0 => /lib/x86_64-linux-gnu/libfribidi.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
                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
    libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0
        libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8
    libwayland-cursor.so.0 => /lib/x86_64-linux-gnu/libwayland-cursor.so.0
    libwayland-client.so.0 => /lib/x86_64-linux-gnu/libwayland-client.so.0
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
    libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.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
    libpangocairo-1.0.so.0 => /lib/x86_64-linux-gnu/libpangocairo-1.0.so.0
        libpangoft2-1.0.so.0 => /lib/x86_64-linux-gnu/libpangoft2-1.0.so.0
        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
            libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1
            libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6
            libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6
    libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
    libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

As you can see, the problem with this build is that I had to link `-lpangocairo-1.0` dynamically because I didn't find the static lib on my system. Although all the Cairo stuff has been linked statically this pulls in libcairo.so.2 with all its dependencies.

I'm stopping this now, maybe you can find a solution like this on your system that avoids linking libpangocairo dynamically...

That said, you can see that I had to link in several X11 related libs statically. That means that you'd need these static libs on your development system but if you can avoid linking libpangocairo dynamically you could maybe succeed.

Good luck and good night from Germany (at 4:37am) - I couldn't resist trying this.

Albrecht

[Rob McDonald]

Thanks for all this help.  I'll have to see what I can do to make something like this work.

I will also run an iteration by them to see what we can get away with.

I found this article that indicates that RHEL10 (expected in 2025) will fully deprecate X11.    That is still a long ways off (unless measured in FLTK release cycles).  It certainly makes clear that FLTK and the entire Linux stack needs to be ready to weather this transition away from X11 once and for all.

Rob

 

[Albrecht Schlosser]

On 3/14/24 05:38 Rob McDonald wrote:

On Wednesday, March 13, 2024 at 8:37:48 PM UTC-7 Albrecht-S wrote:

On 3/14/24 03:46 Rob McDonald wrote:

If the machine is a Wayland machine, I struggle to see why a bunch of X11 libraries would be installed.

Maybe because Wayland or (more likely: other applications) need pango and cairo etc. and therefore the minimal set of X11 libs are also installed.

I believe you should somehow find out which libs are installed on your target system(s), particularly if this is all for one specific organization. For instance, if you knew that they have libpangocairo, then trying to link libpangocairo and all of its dependencies statically would be unnecessary. This would definitely make your task much easier.

I'm approaching this from a perspective of minimizing external dependencies -- statically link everything I can -- don't have a bunch of crud that isn't really needed.

OK, I tried to compile and link hello.cxx statically as a Wayland-only app (linked against a Wayland-only libfltk.a) with several statically linked libs.

[...]

you can see that I had to link in several X11 related libs statically. That means that you'd need these static libs on your development system but if you can avoid linking libpangocairo dynamically you could maybe succeed.

Good luck ...

Thanks for all this help. 

Welcome.

I'll have to see what I can do to make something like this work.

I will also run an iteration by them to see what we can get away with.

If that means, which libs they have installed, I'd clearly go for it.

I found this article that indicates that RHEL10 (expected in 2025) will fully deprecate X11.    That is still a long ways off (unless measured in FLTK release cycles).

I'm striving for much shorter release cycles in the near future, but anyway, who knows...

Thanks for the link, this is interesting. There are also further links to articles about other distros and about KDE and Gnome going the full Wayland route. I'm still reading but I'm wondering if there will really be no XWayland (X server running under Wayland for old X clients). I'd guess that there will be options as add-ons for a long time, otherwise a **LOT** of old programs won't work anymore.

It certainly makes clear that FLTK and the entire Linux stack needs to be ready to weather this transition away from X11 once and for all.

For FLTK this means: we *need* Wayland support (which we have now, thanks to Manolo's efforts) and we must support X11 for old systems for many years, even if major Linux distros and DE's move entirely to Wayland.

[Manolo]

So, there's a residual dependency of FLTK apps to X libraries because the cairo library

present in Linux packages has such dependency.

But it's possible to build differently the cairo library without X dependency, and to use that

alternative cairo library when linking an FLTK app.

Here is a procedure to build and run an FLTK app completely without any X library.

1) build the FLTK library without direct X dependency:

cd <top of FLTK source tree>
mkdir build
cd build
cmake ..  -DFLTK_BACKEND_X11=0 -DFLTK_USE_SYSTEM_LIBDECOR=0 -DFLTK_USE_LIBDECOR_GTK=0
make hello

[we also want to get rid of the gtk plugin of libdecor because GTK-3 has its own X dependencies]

2) download cairo-1.18.0.tar.xz from  https://cairographics.org/releases/

uncompress it in your home directory
cd ~/cairo-1.18.0
edit file meson_options.txt, part "cairo surface backends",
replace "auto" by "disabled" for the xcb, xlib and xlib-xcb lines

meson build
meson compile -C build

at this point, a cairo library that does not depend on X libraries has been built
 
   
3) build a hello FLTK app that's completely X11-free

cd <top of FLTK source tree>
cd test
g++ -o hello hello.cxx `../build/fltk-config --cxxflags` \
../build/lib/libfltk.a \
-lpango-1.0 -lpangocairo-1.0 \
/home/XXXXX/cairo-1.18.0/build/src/libcairo.so \
  -lpthread -L/usr/lib/aarch64-linux-gnu  -lgobject-2.0 -lglib-2.0 \

  -lharfbuzz -lwayland-cursor -lwayland-client -lxkbcommon -ldbus-1 -lfontconfig -ldl \

   -lpng -lz -lm -Wl,-rpath=/home/XXXXX/cairo-1.18.0/build/src
   
replacing XXXXX by your username

run the app:
./hello

List its shared libraries
lddtree hello

Check that no X library is used:
lddtree hello | grep libX

My conclusion is that FLTK 1.4 is today ready for life without X libraries.

[Albrecht Schlosser]

On 3/14/24 15:20 Manolo wrote:
> So, there's a residual dependency of FLTK apps to X libraries because
> the cairo library
> present in Linux packages has such dependency.
>
> But it's possible to build differently the cairo library without X
> dependency, and to use that
> alternative cairo library when linking an FLTK app.

Great finding! I was tempted to say in my recent post that I anticipate
that Linux distros using strictly no X11 would provide such Cairo libs
w/o X dependencies. Your findings make clear that this would be
possible. Thanks.

> My conclusion is that FLTK 1.4 is today ready for life without X
> libraries.

Awesome!

[Rob McDonald]

On Thursday, March 14, 2024 at 6:20:44 AM UTC-7 Albrecht-S wrote:

I believe you should somehow find out which libs are installed on your target system(s), particularly if this is all for one specific organization. For instance, if you knew that they have libpangocairo, then trying to link libpangocairo and all of its dependencies statically would be unnecessary. This would definitely make your task much easier.

 

If that means, which libs they have installed, I'd clearly go for it.

Agreed.  I've requested the output of 

ls /lib64 > librarylist.txt

 

I'm striving for much shorter release cycles in the near future, but anyway, who knows...

I know you are - and I did not mean to criticize in any way.  I mostly just wanted to put the timeframe in perspective.

It certainly makes clear that FLTK and the entire Linux stack needs to be ready to weather this transition away from X11 once and for all.

For FLTK this means: we *need* Wayland support (which we have now, thanks to Manolo's efforts) and we must support X11 for old systems for many years, even if major Linux distros and DE's move entirely to Wayland.

Agreed.

Rob

 

[Rob McDonald]

This is great Manolo -- I suspected that you were already ahead of this game.

Do you think we should consider embedding a Cairo build into FLTK (using ExternalProject or FetchProject) so that our FLTK CMake system can automatically configure and build a Cairo that meets the developer's intent?

The following are rhetorical questions -- me pontificating about the long-term transition to Wayland.  I'm not actually expecting anyone to take action or answer these questions....

I think the interaction with other components is going to be 'interesting'.  For example, I use GLEW to access the OpenGL API in a cross platform way.  Traditionally, GLEW selects between using GLX, WGL, CGL at compile time.  It recently added support for EGL for Wayland, but still as a compile time option.  They are discussing moving to a runtime choice between GLX (X11) and EGL (Wayland).

If both FLTK and GLEW are making a runtime choice between X11 and Wayland, how do we make sure they make the same choice?  is it based on a heuristic, command line flag, environmental variable, something else?  Will there be consensus across tools for how to trigger this choice?

How will an application developer test all the combinations?

Rob

 

[Albrecht Schlosser]

On 3/14/24 17:31 Rob McDonald wrote:

On Thursday, March 14, 2024 at 7:20:39 AM UTC-7 Manolo wrote:

... it's possible to build differently the cairo library without X dependency, and to use that

alternative cairo library when linking an FLTK app.

...

Do you think we should consider embedding a Cairo build into FLTK (using ExternalProject or FetchProject) so that our FLTK CMake system can automatically configure and build a Cairo that meets the developer's intent?

Speaking for myself, not for Manolo: as long as you build your own project and use ExternalProject or FetchProject in your build I believe it would be possible to direct FLTK to use your version of libcairo or whatever you need.

My first thought about the request to include it into FLTK's (CMake) build system was: no, that could easily become too complex (several build options for libcairo, maybe?) and difficult to maintain. A less complicated addition might be to add an option to select a specific Cairo version built by the user on their local system (using either a static or a shared lib, maybe). This needs some investigation and could be considered for 1.5.0.

OTOH, particularly for Windows users, it could be challenging to build their own Cairo lib. Building it optional with FLTK using FetchProject might be an interesting way to enable Cairo support in FLTK w/o the user needing to download and build Cairo.

Personally I didn't try this yet. I downloaded a pre-built Cairo DLL for my internal Cairo tests with FLTK but I'll give it a try...

The following are rhetorical questions -- me pontificating about the long-term transition to Wayland.  I'm not actually expecting anyone to take action or answer these questions....

[...]

If both FLTK and GLEW are making a runtime choice between X11 and Wayland, how do we make sure they make the same choice?  is it based on a heuristic, command line flag, environmental variable, something else?

An interesting question. AFAICT all GUI tools seem to use their own way with their own different environment variables, and so does FLTK. This can be useful if you are using Qt apps that shall use Wayland but FLTK programs that must use X11. If you have two independent decisions (like GLEW and FLTK) I suppose the user would need to set two different environment variables. FLTK has already a commandline flag '-display' to select the X display (in addition to the env variable DISPLAY) but I have no idea how this could be "synchronized" with the GLEW internals.

Will there be consensus across tools for how to trigger this choice?

I doubt that this will ever be possible.

How will an application developer test all the combinations?

How can an FLTK developer test all the combinations?  ;-)

Seriously, we can use CI builds and I'm personally using several parallel CMake builds for FLTK but all combinations of FLTK's build options can hardly be tested. Even if this could be done on one system there could be missing libs on other systems or older system libs etc. that make a particular option combination fail to build. Something like this was the origin of this thread IIRC, wasn't it?

I don't have a good answer to this question, it's only possible to try our best, and that is what an application developer would likely have to do.

[Manolo]

Another approach just experimented :

1) Build FLTK apps as usual with nothing special regarding cairo. The link step will use the default cairo library which is X11 dependent

2) lddtree my-fltk-app

shows that the app pulls in a few X libraries when it's run

3) export LD_LIBRARY_PATH=/home/XXXXX/cairo-1.18.0/build/src

4) lddtree my-fltk-app

shows that the custom-built, X11-independent cairo library is now used when the app runs

==> the FLTK app is X11-independent

About GLEW: The Wayland backend of FLTK already uses the stock libGLEW.so

from Linux packages successfully. There's no difficulty in having GLEW and GL calls in a Wayland client app.

My understanding is that the app calls EGL which calls GL using symbolic function names that

are recognized once GLEW has been activated.

See for example demo program examples/Opengl3test

which is built if option -DFLTK_BUILD_EXAMPLES=1  is set.

About choices between Wayland and x11 that may differ between different elements:

I would suppose the choice is always "use Wayland if possible, otherwise use X11"

which would not create contradictions.