================================================================================
	RPL/2 (R)
================================================================================

--------------------------------------------------------------------------------
	WARNING :

	LESSTIF IS BROKEN AND CORRUPTS HEAP. PLEASE, DO NOT USE LESSTIF INSTEAD
	REGULAR MOTIF LIBRARIES!

	I SHALL NOT ACCEPT ANY BUG REPORT FROM USERS THAT HAVE BUILD RPL/2 WITH
	LESSTIF LIBRAIRIES SINCE OPENMOTIF IS AVAILABLE.
--------------------------------------------------------------------------------

	RPL/2 signifies Reverse Polish Lisp/2. This language is obvious derivated
from the first RPL written by Hewlett-Packard for its 28S calculator. Thus,
this language is a half-compiled high level language which can perform
symbolic and scientific computations.

  * RPL/2 is known to run on :

	- Linux (kernel 2.6.12 and above) on i386, amd64, ppc32, sparc32,
		sparc64, alpha. Test distribution is Debian. Warning, you have to
		use NPTL, not LinuxThreads due to a bug in sem_post() that is not
		async safe.
	- Solaris 9 and above on i386, amd64, sparc32 (only Solaris 9) and sparc64.
		It can be built out of the box on Solaris in a 32bits userland. For a
		64bits executable, you have to modify some generated makefiles. See
		64bits on Solaris.
	- FreeBSD 7.0 on i386.
	- NetBSD 4.0 and above on sparc32 with a restriction. NetBSD's sigpending
		is broken and it is impossible to use DETACH intrinsic. Bug report
		has been done and this bug should be fixed in next NetBSD release.

  * RPL/2 should run on :

	- HP-UX (10.20 and above), but not tested for a long time.
	- Linux (2.6.12 and above) on ppc64 and other hardware (arm, hppa...) or
		with other distributions than Debian.
	- FreeBSD 7.0 and above on other architecture than i386.
	- NetBSD 4.0 and above on other architecture than sparc32 with restriction
		due to sigpending bug.
	- Mac OS X.

	Any information about RPL/2 on these last operating systems are welcome.

  * RPL/2 is not supported on :

	- OpenBSD due to a major bug in sigaltstack syscall when a program is
		linked with -lthread. As this bug comes from OpenBSD libraries,
		OpenBSD port has to wait for a fixed sigaltstack.
	- OpenVMS (work in progress) on both VAX and Alpha due to some bugs in GNV.
	- Hurd (vaporware...).

  * RPL/2 shall never be supported on :

	- Cygwin due to some troubles between Cygwin Posix subsystem and Windows.
		You can try, but I shall never support Cygwin. If someone proposes
		patches to build RPL/2 on Cygwin, I won't modify official RPL/2 source
		tree, but only propose these patches against official tarball.
	- Windows (all versions).
	- OS/2 and eComStation.
	- Mac OS preX.

	Tools directory contains some libraries that are normally provided by
	all Posix systems. These libraries are built during build process
	and RPL/2 is statically linked with them because I have seen that on
	several systems, some Posix libraries have strange 'features'...

	On all systems, you must install GNU make and you should install
	gcc/g++/gfortran (minimal release : 4.0.0). It is possible to build
	RPL/2 with some other compilers (for example cc and f95 from SunStudio,
	or cc and f95 from Digital^WCompaq^WHP) but I do not test all potential
	combinaisons.

  * 64 bits on Solaris (are you sure that you need 64bits wide RPL/2 ?)

	You have to configure RPL/2 with some user defined variables.

	CFLAGS="$CFLAGS -m64" CXXFLAGS="$CXXFLAGS -m64" FCFLAGS="$FCFLAGS -m64" \
			FFLAGS="$FFLAGS -m64" LDFLAGS="$LDFLAGS -m64" ./configure (options)

	If you want to use mysql or postgresql support, you should obtain 64bits
	binary executables, libraries and daemons. PostgreSQL 8.3.5 does not compile
	on Solaris 10 in 64bits mode with gcc/GNU ld (due to a strange bug, ld
	tries to build a 32bits wide library with 64bits objects even if -m64 is
	specified on command line...). I have not tried mysql.

	If you want to use rplc, you have to use GNU ld, not Solaris ld, due to
	another bug that avoid symbol exportation. You have to check that rpl
	is linked with libmtmalloc and not with libmalloc from libc because there
	is another bug in Solaris' libc : free() can enter in a deadlock
	(internal locked mutex).

	Of course, all 64bits libraries have to be accessible by LD_LIBRARY_PATH.

tchaikovski:[/usr/shared-apps/bin] > file rpl
rpl: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked,
     not stripped

	Very easy^Wnice, isn't it ?

	J. Bertrand <joel.bertrand@systella.fr>