[ 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 ]
[ Submit Comment ]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 ] |