Artifact cc624cfd9462ad69f7819ddc0542d73d2af35f058009b0ad89b3409e52ab2851:
- Executable file
r38/lisp/csl/cslbase/PLATFORM.NOTES
— part of check-in
[f2fda60abd]
at
2011-09-02 18:13:33
on branch master
— Some historical releases purely for archival purposes
git-svn-id: https://svn.code.sf.net/p/reduce-algebra/code/trunk/historical@1375 2bfe0521-f11c-4a00-b80e-6202646ff360 (user: arthurcnorman@users.sourceforge.net, size: 6388) [annotate] [blame] [check-ins using] [more...]
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.