On my system, this spits out a bunch of libraries, and the
interesing ones are
libfltk.so.1.4 (libc6,x86-64) => /lib/x86_64-linux-gnu/libfltk.so.1.4
libfltk_cairo.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libfltk_cairo.so
libfltk_cairo.so.1.4 (libc6,x86-64) =>
/lib/x86_64-linux-gnu/libfltk_cairo.so.1.4
On 22/12/2025 20:09, Lorenzo Sutton wrote:
No cairo ones here :-(
/usr/lib/libfltk.so
/usr/lib/libfltk.so.1.4
/usr/lib/libfltk.so.1.4.4
/usr/lib/libfltk_forms.so
/usr/lib/libfltk_gl.so
/usr/lib/libfltk_images.so
Then next let's try out if any one of those provides the funcition we need
nm -D <library-with-full-path> |grep cairo_make_current
Here:
nm -D /usr/lib/libfltk.so.1.4 | grep cairo_make
no output.
I noticed indeed that in
/usr/include/FL/Fl.H and /usr/include/FL/Fl_Cairo_Window.H
#ifdef FLTK_HAVE_CAIRO
Hi Lorenzo,
thanks for looking into all those details and helping us
with understanding the situation.
What you point out is indeed an important observation.
So obviously, the FLTK 1.4 installed on your system has been built
without the Cairo-bridge. But the new solution proposed by Jesper
does rely on this feature to allow us to use our custom drawing.
I have just checked the configure-script of the FLTK source package
./configure --help
....
Optional Features:
--disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
--enable-cairo add support for Fl_Cairo_Window
--enable-cygwin use the Cygwin DLL (default=no)
--enable-debug turn on debugging
...
...
So that means, a version of FLTK to support our custom drawing
under wayland thus needs to set --enable-cairo at build time.
The Debian package does that, and likely this was /not/ done for
Manjaro (while this could both be deliberate or a mistake, it
is something only the distribution people can change).
So the conclusion is, Lorenzo, unless you want to dig further
and build FLTK for yourself (or find some further info for
your Distro, Manjaro or Arch, maybe some custom variant
or AUR package for FLTK built with Cairo), there is not much
you can do in this situation.
The Patch proposed by Jesper looks likes the most favourable
solution, because it means that we (the Yoshimi project) do
not have to maintain some extra stuff, but rather directly
hook into the solution intended by the FLTK developers.
@Will how shall we deal with this situation?
I see two quite different approaches....
- we could say, we just require that Cairo support from now on,
and thus open a bug for Manjaro and maybe other distros which
still miss that. And publish that people need a FLTK configured
with Cairo support in order to build Yoshimi.
- or, going into the other direction, we could add a further
macro and branching to the code, which triggers if we have
FLTK >= 1.4 but not defined FLTK_HAVE_CAIRO
We could fall back to just calling the inherited draw() function
and disable the bandwidth diagram for Subsynth.
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
