BUILDING ON VARIOUS PLATFORMS.
The code here, together with the FOX toolkit, have been built and tested on
a range of systems. The file is a place to collect comments on special
treatment that was needed in some cases.
In general with any system it will be necessary (or at least best) to
ensure that autoconf, automake, libtool are installed, together with
the develoment support for X11. Xft and (n)curses should also be installed.
On old systems the versions of autoconf etc supplied may be too old to
be usable. The support-packages directory contains versions expected to
be adequate, and these can be unpackes, built and installed in the usual
manner. Those who find that an undue challenge should stick to building this
code on recent releases of operating systems and development tools!
In my testing I will always have run an on-line update to bring the
operating system and all the developers tools to as fresh a state as
possible before trying my build. Of course yet later updates may break
something else...
February 2007:
Systems tried:
RedHat 6.2 OK after custom patch - see below
RedHat 7.2 OK
RedHat 8.0 OK after "export SED=sed" - see below
RedHat 9 OK
Fedora Core 2 OK
Fedora Core 4 OK
Fedore Core 5 OK
Fedora Core 6 OK (I have trouble getting VMware tools installed)
Debian 3.1 OK
... Ubuntu 6.10
... SuSE
64-bit OpenSuSE 10.2 OK
MacOS 10.3 (Panther) OK
MacOS 10.4 (Tiger) OK - build is for ppc and i386 as FAT binary
Windows XP OK
Windows/cygwin OK
Windows Vista a quick check on the release candidate for Vista
does not show up and disasters.
Windows XP 64 OK, but created as a cross-build and not heavily
tested. The build process, being nonstandard,
is to be considered "unsupported"
Windows Vista 64 doubly unsupported, but a quick check looks OK.
Solaris 10 x86 OK, but it is essential to have the "companion DVD"
installed so that gcc, autoamake etc are
available. Xft fails utterly for me.
The earliest Red Hat that I have tried is 6.2. I had to work tolerably
hard to get an environment with all the tools I needed that would run happily
under VMware for me, and despite all the autoconf tools when I tried to
build FOX I found one compilation failure relating to options for reading
the clock. Because I believe that is now a system of historical rather than
practical interest I patched FXThread.cpp in the function FXThread::time
to use gettimeofday rather than clock_gettime by making a minor change to
an existing #ifdef. I do not intend to move that patch back into my main
sources or investigate further, because with that small adjustment I could
build workable binaries.
RedHat 8.0 gave me trouble that I do not feel that I understand fully,
but to allow libtool to run properly I appeared to need to go
export SED=sed
before starting any attempt to build things. Without that the symptom
observed was amoan to the effect that a command "-e" was not found.
Again I view the platform as ancient enough that I am not going to chase
this further and automate a fix, especially since the apparent cure is just
to set a shell variable.
It looks as if an install from a Debian 3.0 CD set followed by online
updates ends up with a Debian 3.1 system, so I am not providing any
explicitly 3.0-series builds.
Ubuntu: An initial Ubuntu install is fairly minimal. When I move executables
across to it and try them they may fail abjectly - probably because of the
lack of some vital dynamic library. But things improve greatly when I
fetch and install a reasonably comprehensive development environment. This
effect may well appply to most other distributions.
Windows: I build from a cygwin shell, and it is important that enough
of the cygwin build tools have been installed. I compile in the "no-cygwin"
or "mingw" mode, so that standare Windows libraries are used rather than
the cygwin ones.
Windows-cygwin: The build scripts make provision for forcing use of cygwin,
but because the main cygwin library is subjec to the GPL you do not have
permission to redistribute a system built that way.It may be a useful option
while debugging X-windows aspects of the code while running on Windows.
Windows-64: I used the command-line compilers from the Windows SDK, and use
them from a cygwin shell. That allows me to build 64-bit executables
while running on 32-bit windows. Setting up that build environment that
way is perhaps a little delicate, and it is not possible to build 64-bit
image files as part of a cross-build. I will not view this platform as
"supported" until there is a stable release of the cygwin/mingw build
tools for 64-bit windows.
Windows Vista: As cygwin/mingw becomes stable I expect 32-bit builds to
happen just as they did on XP. The situation about Vista-64 is much the
same as that for XP-64.
Solaris: The version built on was SunOS 5.10, 11/06 with lots of useful
tools from the companion CD installed. Note that the extra packages have to
be installed using "pkgadd". I found development most convenient it I put
/usr/sfw/bin and /opt/sfw/bin on my PATH, but I have tried to make the
build scripts so that they do not rely on that. But in consequence they do
rely on all the tools being installed at the locations that they get put
in my default. Note that one needs to use "gmake" or even /usr/swf/bin/gmake
to build bits of the code if doing so manually.
I had installed the 64-bit version of Solaris, but the default mode for
the C compiler appears to be to create 32-bit executables. The "-m64"
option may change that, but I am not experimenting with that right now.
I am also not trting other releases of Solaris, or the version running on
sparc rather then i386.
On Solaris if I use Xft and my customised Type1 fonts something crashes
abruptly as I attept to open the font, and so at least as a temporary
measure I have disabled the detection of Xft on that platform. That would have
consequences if you run the code on a different machine from the one that
provides the X server, in that custom maths fonts will then not be rendered.