----------------------------- ZSH ON SPECIFIC ARCHITECTURES ----------------------------- These are the OSes that zsh has been tried on. If you succeed in getting zsh to work on an OS not listed, let us know. The information in this list may be out of date, as the developers do not have access to all machines. In general, GNU/Linux distributions, Solaris and Cygwin are reasonably well covered. Please let us have any recent information on other systems. The information for systems not known to have been tested recently is marked as `out of date'. On all machines if you use gcc and upgrade your OS you must rebuild gcc after the OS upgrade. A gcc left from a previous OS may seem to work but compiling more complex programs may fail mysteriously. The format of entries is thus: Vendor: OS & version (hardware type) [zsh version tried] information Machines -------- Apple: MacOS X/Darwin 10.x Should build `out-of-the-box'. For dynamic loading to work on 10.1 and 10.2, you need to use the dlcompat library. It can be downloaded from: http://sourceforge.net/project/showfiles.php?group_id=17203 The zsh/zpty library is not working on 10.1 and 10.2, but is on 10.3. This causes the tests starting `Y' in the Test directory to fail, even though the features to be tested are working. Reported to compile with no problems on 10.4. Compiling with GCC on 10.9.1 (Mavericks) reportedly causes a crash due to a libiconv problem. Compile with clang instead. Multibyte support works; you probably wish to set the option COMBINING_CHARS, which is not enabled by default. Problems have been noted when outputting multibyte characters to the terminal from a "preexec" function. Red Hat Inc.: Cygwin Should build `out-of-the-box'. The compilation directory should be on a file system mounted as binary (the mount command shows `binmode'). There are various issues with Cygwin versions before 1.3.2 - you are adviced to update to the latest release. Process substitution using <(...), >(...), =(...) may be problematic. Different versions of zsh and Cygwin have a different mix of issues. Problems handling subprocesses have been reported with Cygwin 1.7.5. It is not currently known how the problems split between Cygwin and zsh. Some of the tests in the Test subdirectory are known to fail: this is because the UNIX environment is not completely implemented. Cygwin allows mount without existing mount point (e.g. "mount //server/path /usr/src" where /usr/src does not exist). Path completion will fail inside these mounts; make sure that every mount point really exists. FreeBSD: FreeBSD 2.2.7, 3.x, 4.x, ... 7 Should build `out-of-the-box'. On FreeBSD 2.2, dynamic loading does not work, but it does with 3.x and later. HP: HP-UX 9, 10.20, 11.x (PA-RISC, Itanium) Should build `out-of-the-box'. Previous problems encountered on HP-UX 11.x: Some of the special keys on the keyboard (backspace, delete) have been found to stop functioning. One suggested fix is to alter the way the curses library is linked in the Makefile. Replacing `-lcurses' with `-lHcurses -lcurses' in the libraries is reported to fix this on 11.0, but is no longer necessary on more recent versions of HP-UX 11, i.e. 11.11+. Typical gcc installations on HP-UX use HP's linker rather than the GNU one. Configure will fail to set up dynamic linking in this situation. The following should allow building of modules: DLLD=/usr/ccs/bin/ld DLLDFLAGS=-b DLCFLAGS=-fpic ./configure ... Compiling with gcc 2.7.1 is known to fail with header file conflicts. Use the HP ANSI C compiler. IBM: AIX 3.2, 4.x, 5.x Should build `out-of-the-box'. Certain features will not work, in particular --enable-cap and --enable-zsh-mem. (The feature enabled by --enable-cap is apparently present, however. Help getting this to work would be appreciated.) On 3.2, for 64-bit integer support you need to compile with gcc, as the native compiler does not support ANSI simultaneously with `long long'. On 4.1, there appeared to be problems using --enable-dynamic (the default) with gcc (version was 2.7.2.3), though native cc works. More information about this problem would be appreciated. It was reported, that at least some 4.x versions have problem with curses - variables boolcodes and some other are declared in term.h but missing is libcurses.a. That makes native compiler very unhappy (GCC 3.0 apparently does not mind). Zsh now defaults to termcap on AIX; any info about this problem is appreciated. Linux: Linux 2.x, 3.x (various 32-bit and 64-bit processors) Should build `out-of-the-box'. The following problems should not occur with recent distributions. If you are using an early minor version of libc 5, then a bug in the auto-configuration process may cause zsh to think that your system doesn't support the lstat function. If the configure process reports that there is no lstat, edit config.h and change HAVE_LSTAT to 1. libc-5.2.18 or later does not have this problem. Some versions of glibc2 have a conflict with which causes a redefinition warning on RLIM_INFINITY. This causes configure to decide that is not present, which can cause compilation errors in zsh's rlimit code. The best solution is to edit config.h after running configure and #define HAS_SYS_RESOURCE_H. NetBSD: NetBSD 1.x Should build `out-of-the-box'. OpenBSD: OpenBSD 2.x, 3.x Should build `out-of-the-box'. OpenIndiana: OpenIndiana 151a Problems have been reported with awk when used to generate prototype files for building zsh. Upgrading to gawk (GNU awk) version 4.0.0 fixes this. Sun: Solaris 2.x, 8, 9, ... It is recommended that the system library version of iconv() be used rather than libiconv since there are incompatibilities in the way codesets are named. The UCB versions of the routines for reading directories are not usable (the struct definitions are incompatible with the ones assumed by zsh). The symptom of this is that globbed filenames in the compiled version of zsh will be missing the first two letters. To avoid this, make sure you compile zsh without any reference to /usr/ucblib in your LD_LIBRARY_PATH. You can easily do this by just unsetting LD_LIBRARY_PATH before building zsh. Problems were once reported using --enable-largefile (the default) to enable large file system and integer support on Solaris 2 with gcc before 2.95.2. Recent versions of gcc appear to be unproblematic. Other machines -------------- Zsh has previously been compiled on the following machines, but the developers do not have direct access to them and the reports may be out of date. Some of these OS's are now very long in the tooth. We would be glad to receive any reports of success or failure on these OS's --- and, of course, any others not mentioned in this file. Apple/NeXT OpenStep 4.2 for i386. Reported to work at least with gcc 2.8.1 and gawk 2.15 patchlevel 6, but not with the bundled cc 2.7.2.1 and awk. Cray: Unicos (C90 and T90) Should build `out-of-the-box'. Data General: DG/UX 5.4R3.10 MU01 (various AViiONs) Should build `out-of-the-box'. DEC: Ultrix (Alpha or DECstation) DEC: Mach 3.0 (DECstation 5000/25) DEC: OSF/1 1.2, 1.3, 2.0, 3.x, DEC Unix 4.x (Alpha) HP/Compaq: Tru64 4.x, 5.x Next: NextStep 3.* Should build `out-of-the-box', but the zsh malloc routines are not recommended. SCO: UnixWare 2.1.3 Builds `out-of-the-box'. SGI: IRIX 6.2, 6.3, 6.5 SIEMENS: SINIX SIEMENS: Reliant UNIX Sun: SunOS 4.1.x