/
MACHINES
265 lines (205 loc) · 10.3 KB
/
MACHINES
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
-----------------------------
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.
Multibyte support works, although (as on other architectures)
Unicode combining characters are not properly handled.
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.
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)
[Out of date.]
In OSF/1 3.x, there is apparently a bug in the header file
/usr/include/rpcsvc/ypclnt.h; the prototype for yp_all() has a
struct ypall_callback as its final argument, which should be a
pointer (struct ypall_callback *). This prevents compilation of
one of zsh' files (zle_tricky.c). If you can't modify the header
file, create a directory called `rpcsvc' in zsh's Src subdirectory
and put a fixed version of the header file to it before compiling.
The strip coming with gcc-2.7.2 seems to create unusable binaries.
This problem is not related to zsh. If you have such problems,
remove the bogus strip and use /bin/strip instead.
On Digital UNIX 4.0, compilation with gcc and with --enable-dynamic
apparently needs configuring with explicit flags when compiling
with debugging enabled:
DLLD=gcc LDFLAGS='-g -rpath <path-to-.so-files>' ./configure ...
FreeBSD: FreeBSD 2.2.7, 3.x, 4.x
Should build `out-of-the-box'. On FreeBSD 2.2, dynamic loading
does not work, but it does with 3.x and 4.x.
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.
HP/Compaq: Tru64 4.x, 5.x
Should build `out-of-the-box'.
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 (various 32-bit and 64-bit processors)
Should build `out-of-the-box'.
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.
Various problems have been reported when using optimisation
with the experimental GNU compiler, egcs. In particular,
on Linux Alpha with egcs 1.0.3a and 1.1.1 using -O1 or greater,
the completion code is not correctly compiled.
Some versions of glibc2 have a conflict with <asm/resource.h>
which causes a redefinition warning on RLIM_INFINITY. This
causes configure to decide that <sys/resource.h> 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.
SIEMENS: Reliant UNIX
[Out of date.]
Builds `out-of-the-box'. Dynamic loading is supported.
Large Files and 64-bit integers are supported as of version 5.44
and CDS/CDS++ compiler.
SIEMENS: SINIX
[Out of date.]
MX (Intel) platform: SINIX-L/M 5.41
Builds out-of-the-box with EGCS. Neither dynamic loading nor
64-bit integers are supported. Native compiler was not tried
mostly because GCC/EGCS builds out-of-the-box as well. If you
succeed with native compiler, send a patch for this file
to zsh-workers.
RM (MIPS) platform: SINIX-N/Y 5.42
Should build out-of-the-box but it was not tested. Neither
dynamic loading nor 64-bit integers are supported.
Note, that this version is obsolete and users are expected to
update to Reliant UNIX.
SGI: IRIX 6.2, 6.3
[Out of date.]
Should build `out-of-the-box'.
SGI: IRIX 6.5
Should build `out-of-the-box'; however, if using the native
compiler, "cc" rather than "c99" is recommended. Compilation
with gcc is also reported to work. Multibyte is supported.
On 6.5.2, zsh malloc routines are reported not to work; also
full optimization (cc -O3 -OPT:Olimit=0) causes problems.
If using the SGI compiler, variable length arrays need to
be turned off. configure can work this out for itself if it
is passed the option --enable-cflags='-LANG:vla=off -O' (combined
with other flags if necessary).
The zpty module is not currently supported. This causes the
tests starting `Y' in the Test directory to fail, even though
the features to be tested are working.
Sun: SunOS 4.1.x
[Out of date.]
Under 4.1.3 if yellow pages is used, username completion may cause
segmentation violation. This is a bug in the shared library not
in zsh. Some libc.so.1.9.* has this bug (it fails in yp_all).
Statically linked binaries will work if linked with libc.so.1.8.1
(which means that if you can get a statically linked binary
compiled under 4.1.2 that it will probably work). An alternative
but untested solution may be to undefine HAVE_NIS in config.h.
This may work, but the first username completion will be _very_
slow (as slow as in tcsh).
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. 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'.
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'.