[ Return to Articles | Show Comments | Submit Comment ]
Article #1352: Notes on building fltk-1.3.x with nano-X / nxlib / microwindows
Created at 13:12 Feb 26, 2014 by ianmacarthur
Last modified at 13: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
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;
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
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);
GdImageBufferRead(pstruct->io_ptr, pointer, size);
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
printf left in from
Edit the file Text16.c and replace the single
printf with a
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 \
(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
fltk-config files to replace each occurrence of
-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…)
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
This happens because fltk attempts to dynamically load
XRANDR support on the fly at runtime, which does not go too well…
Modify the file
and, just after it defines
add the following line
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
to ask for fonts that are actually on your system
I know Georg favours the
approach whereas I tend to just hack
to pick up whatever fonts I have to hand...
[ Listing ]
[ Submit Comment ]