Porting People -------------- The following people have helped ensure that CSSC has worked on these platforms (at some stage): James Youngman Red Hat Linux (x86) 4.1,4.2,5.0,5.1,5.2,5.9, 6.0, 6.2, 7.0, 7.1, 7.1.93 James Youngman Debian GNU/Linux versions 2.2 (SPARC64, Alpha), 3.0 (x86) James Youngman HPUX 9 (PA-RISC) James Youngman Solaris 2.6 (SPARC), Solaris 2.8 (SPARC) Lars Hecking Solaris-2.5.1 Malcolm Boff Solaris-2.5.1 Lars Hecking IRIX 6.3 (GCC 2.7.x configured for IRIX 5.3) Lars Hecking IRIX 6.3 (GCC 2.8.0) Richard Polton IRIX 5.3 Dave Bodenstab FreeBSD-2.0.5-950622-SNAP Andy Sharp FreeBSD-2.2.2-RELEASE James Youngman FreeBSD 4.3-RELEASE (x86) Lars Hecking [*] SunOS 4 Mark Reynolds SunOS 4.1.3 Lars Hecking [*] AmigaOS (ixemul) Andrew Bardsley [*] GNU Hurd James Youngman Dynix/ptx 4.2 Mark Reynolds Ultrix 4.2 [SEE BELOW!] [*] These entries denote that CSSC compiled successfully but the test suite was not run. Because GNU CSSC uses GNU "autoconf" to generate configuration scripts, it's reasonable to expect CSSC to work on almost any version of Unix with little or no modification. If modification is required, it is best to modify "configure.in" appropriately and let "configure" determine what needs to be done. However, if you do not have GNU Autoconf installed you will not be able to regenerate "configure" from "configure.in". In any case, please let the maintainer know about these required modifications (see the README file in the distribution directory). Don't forget also to explain clearly *why* these modifications are required, and on what systems. The Makefile generated by the configure script appears to work with GNU make but not always with the "make" utility that comes with all platforms; if the "-include" line makes your "make" utility fall over, try GNU make. If you wish to install GNU Autoconf, you can obtain it from the GNU Project's FTP site, ftp.gnu.org. You will probably also find GNU Automake useful. CSSC has not, as far as I know, been widely tested with C++ compilers other than GCC:- GCC (2.7,2.8,EGCS) Compiles, test suite passes GCC (3.0) Compiles, test suite passes EPC C++ Compiles, test suite passes IRIX CC Fails to compile (see below) Notes for specific platforms ============================ Linux ----- The code should build without problems as-is. There is a workaround for a bug in a few versions of glibc. See "GNU libc" below for more details. Solaris ------- You need to build CSSC using GNU make because of the way that the dependencies are used in the Makefile. HPUX ---- To compile on HPUX 9 you have to use GNU make and /bin/posix/sh: $ SHELL=/bin/posix/sh $SHELL ./configure $ gmake SHELL=/bin/posix/sh IRIX ---- To compile on IRIX it appears that GNU make is required. CSSC also does not compile with IRIX's native cc, "CC". The IRIX compiler seems not to support static template instantiation. (Thanks to Achim Hoffmann for this information). Ultrix 4.2 ---------- Mark Reynolds has run the test suite on this platform (at CSSC version 0.11 alpha.pl2). All the tests except one pass. In the failing test, we get a coredump:- > All tests pass, except that anything involving get -r ANYTHING -p > ... or get -r ANYTHING -s core dump. Again, when I have isolated the > problem I will send a more detailed report along with (hopefully) > patches. To run the tests on this platform, one must use Bash :- > Because this OS is so ancient, it is not possible to run "make > check" out of the box. Both "sh" and "sh5" (the Sys V version of sh) > give syntax errors loading the defs in common. However "make > SHELL=bash check" does run (I'm using bash 2.03). NetBSD ------ The Texinfo feature @env{} is not supported by version 1.68 of Makeinfo which comes with some versoins of NetBSD. To work around this problem, you could apply the following sed command to "cssc.texi":- sed -e 's/@env{\([^]]*\)}/@code{\1}/' FreeBSD ------- You will nedd to build with GNU make. GNU libc -------- GNU libc 2.2.3 has a bug in it which means that if you use GCC 2.97 or later, classes cannot have member functions called "printf". The configure script works around this problem (by turning off optimisation). The glibc bug is fixed in glibc 2.2.4. CSSC compiles successfully under GCC version 3.01, with this workaround in place. Windows NT ---------- CSSC compiles under the CYGWIN environment for Windows NT. CSSC support inder the Cygwin environment is nearly up to the standard of Unix implementations, but there are three significant areas in which it falls short :- 1. Files are often created with the wrong mode, but for the most part the relevant program changes the mode of the output file to the correct value immediately after closing the file. 2. The "Atomic" NFS locking support (which is done on Unix with the use of link(2) requires the ability to use link(2) on an open file; this is a feature which is not supported under the Cygwin environment. For this reason, it is unsafe to use the Cygwin version of CSSC on SCCS files which are mounted via an NT NFS client. If, on the other hand, the files are mounted via Samba, this should be safe (but has not been tested). 3. Set-user-id execution will not work properly. Because of the insecure nature of the current code base, this mode of operation is not currently supported anyway, but this is liable to be especially poor under Windows NT due to the significant differences in the security models of Unix and Windows NT. The Cygwin environment does provide tools for resolving this problem, but this has not been done. A small number of the test cases for the "sccs.exe" binary fail under CYGWIN; this is because, although they do the right thing, the output messages are in the wrong order. The reason behind this is that under Unix when you use "sccs unedit" the output of "get" appears before the output of the "unget()" function, even though the unget() happens first. This is because the output of the unget() function is buffered and hence is only flushed to the output file when the parent process exits. The stdio buffering arrangements for CYGWIN seem to be slightly different, and this changes the ordering. For this reason, test "h1" currently fails, and is skipped for CYGWIN.