[ Return to Articles | Show Comments | Submit Comment ]

Article #1352: Notes on building fltk-1.3.x with nano-X / nxlib / microwindows

Created at 10:12 Feb 26, 2014 by ianmacarthur

Last modified at 10:13 Feb 26, 2014

There have been queries on the mailing lists from time to time about using fltk-1.3 with microwindows/nano-X.

These tests worked as described as of February 2014.

Historically (i.e. in the fltk-1.0 and fltk-1.1 era) a patched version of fltk, known as flnx, was used with nano-X.

However, using nano-X’s nxlib layer to emulate X11 more closely, it is feasible to build an essentially “stock” fltk-1.3 library using nano-X.

For the purposes of this note, we will describe the process running nano-X in a window under a “real” X-server, running on an F17 host system

It is assumed that anyone needing to run fltk/nano-X on an embedded target board would already understand the issues pertaining to cross-compiling their code for the target hardware.

For this test, I obtained the following nano-X source tarballs;

microwindows-full-snapshot.tar.gz

and

nxlib-src-snapshot.tar.gz

Both downloaded on the 7th Feb 2014.

The microwin/nano-X build was configured in the usual fashion, selecting X11 as the backend for rendering to.

However, microwin fails building as follows, because of incompatibilities in the libpng versions used (F17 seems to provide a “too modern” PNG library.)

file image_png.c: In function ‘png_read_buffer’

Changed to this:

/* This is a quick user defined function to read from the buffer instead of from the file pointer
*/
static void
png_read_buffer(png_structp pstruct, png_bytep pointer, png_size_t size)
{
#if (PNG_LIBPNG_VER >= 10510)
    png_voidp ptr =  png_get_io_ptr(pstruct);
    GdImageBufferRead(ptr, pointer, size);
#else
    GdImageBufferRead(pstruct->io_ptr, pointer, size);
#endif
}

Nano-X then built OK until it tried to build the vncauth test section, even though I had configured for NO VNC.

Move VNC folders aside and rebuild... That went better!

Then cd to the nxlib folder and build that: Build of nxlib proceeded without issues.

One minor change, the issue of nxlib I obtained had an errant printf left in from testing.

Edit the file Text16.c and replace the single printf with a DPRINTF instead.

For the fltk part of the test, I used fltk-1.3.x-r10109.tar.bz2 but I assume any recent version would do.

Now cd into the fltk build folder and configure as:

./configure --x-includes=/home/test/src/nanoX/nxlib/X11 \
  --x-libraries=/home/test/src/nanoX/microwin/src/lib \
  --disable-gl \
  --disable-xinerama \
  --disable-xft  \
  --disable-xdbe \
  --disable-xfixes

(You will need to set the paths above to point where your nano-X and nxlib folders actualy are of course!)

Then hand-edit the auto-generated

makeinclude   and   fltk-config   files to replace each occurrence of

 -lX11

with

-lNX11 -lnano-X -lfreetype

(Note: I’m not sure the –lfreetype is really needed here, but Georg says he always includes it, and so I just left it in…)

and add -L/home/test/src/nanoX/nxlib to the library search path.

Then I built the lib with:

make –k –j3

Note that the –k is required to stop the build choking when it tries to build the Sudoku example, which fails for want of a missing X11 service that nxlib doesn’t emulate.

The lib and all the examples build much as usual.

However, when trying to run them in the nano-X window, they segfault.

This happens because fltk attempts to dynamically load XRANDR support on the fly at runtime, which does not go too well…

Modify the file Fl_x.cxx and, just after it defines XRANDR, add the following line

#undef XRANDR

to suppress XRANDR support from being requested.

Rebuild the library, and all should be well.

In my tests, the fltk samples all then run much as expected in the nano-X window.

One issue that may arise is font handling. In that the fltk apps don’t find the expected default fonts.

There are two schools on this:

1. Create a fonts.alias file to remap the fltk default names onto fonts that your system actually has (e.g. fltk asks for “helvetica”, “courier” and “times”, so you might alias these to “arial”, “courier new” and “times new roman”, and so forth.)

2. Modify the list of fonts request by fl_font_x.cxx to ask for fonts that are actually on your system

I know Georg favours the fonts.alias approach whereas I tend to just hack fl_font_x.cxx to pick up whatever fonts I have to hand...

[ Listing ]

Comments

From greg.ercolano, 18:00 Jan 21, 2019 (score=3)

> Modify the file Fl_x.cxx and, just after it defines XRANDR, > add the following line > #undef XRANDR > to suppress XRANDR support from being requested.

As Daniel G points out in his post on fltk.coredev (Jan 21 2019, thread Subject: "Statically linking NanoX fails"), apparently for fltk-1.3.4-1, one must additionally do an #undef XRANDR in screen_xywh.cxx as well, to avoid a segfault at runtime.
[ Reply ]