Mercurial > hg > xemacs-beta
annotate PROBLEMS @ 5276:dd2976af8783
Add some missing #includes, termcap.c, hopefully fixing Adam Sjoegren's build.
2010-09-18 Aidan Kehoe <kehoea@parhasard.net>
* termcap.c:
Add a couple of missing includes here, which should fix builds
that use this file. (I have no access to such builds, but Mats'
buildbot shows output that indicates they fail at link time since
DEVICE_BAUD_RATE and IS_DIRECTORY_SEP are available.)
| author | Aidan Kehoe <kehoea@parhasard.net> |
|---|---|
| date | Sat, 18 Sep 2010 15:03:54 +0100 |
| parents | 1a9c94ba117c |
| children | 388762703a21 |
| rev | line source |
|---|---|
| 278 | 1 -*- mode:outline -*- |
| 2 | |
| 0 | 3 This file describes various problems that have been encountered |
| 197 | 4 in compiling, installing and running XEmacs. It has been updated for |
|
4634
c064d7197712
Add historical deprecation to PROBLEMS.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
3863
diff
changeset
|
5 XEmacs 21.5. Note that the issues are by now mainly historic; XEmacs |
|
c064d7197712
Add historical deprecation to PROBLEMS.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
3863
diff
changeset
|
6 no longer depends on bleeding edge features of operating systems, but |
|
c064d7197712
Add historical deprecation to PROBLEMS.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
3863
diff
changeset
|
7 rather is quite conservative. Operational issues (common user |
|
c064d7197712
Add historical deprecation to PROBLEMS.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
3863
diff
changeset
|
8 misunderstandings and such) are described in the FAQ, not here. |
| 0 | 9 |
| 278 | 10 This file is rather large, but we have tried to sort the entries by |
| 11 their respective relevance for XEmacs, but may have not succeeded | |
| 12 completely in that task. The file is divided into four parts: | |
| 124 | 13 |
| 197 | 14 - Problems with building XEmacs |
| 15 - Problems with running XEmacs | |
| 16 - Compatibility problems | |
| 17 - Mule issues | |
| 120 | 18 |
| 197 | 19 Use `C-c C-f' to move to the next equal level of outline, and |
| 223 | 20 `C-c C-b' to move to previous equal level. `C-h m' will give more |
| 21 info about the Outline mode. | |
| 120 | 22 |
| 197 | 23 Also, Try finding the things you need using one of the search commands |
| 24 XEmacs provides (e.g. `C-s'). | |
| 25 | |
| 524 | 26 General advice: |
| 957 | 27 |
| 524 | 28 WATCH OUT for your init file! (~/.xemacs/init.el or ~/.emacs) If |
| 29 you observe strange problems, invoke XEmacs with the `-vanilla' | |
| 30 option and see if you can repeat the problem. | |
| 197 | 31 |
| 957 | 32 Note that most of the problems described here manifest at RUN |
| 33 time, even those described as BUILD problems. It is quite unusual | |
| 34 for a released XEmacs to fail to build. So a "build problem" | |
| 35 requires you to tweak the build environment, then rebuild XEmacs. | |
| 36 A "runtime problem" is one that can be fixed by proper | |
| 37 configuration of the existing build. Compatibility problems and | |
| 38 Mule issues are generally runtime problems, but are treated | |
| 39 separately for convenience. | |
| 40 | |
| 120 | 41 |
| 124 | 42 * Problems with building XEmacs |
| 197 | 43 =============================== |
| 0 | 44 |
| 373 | 45 ** General |
| 1245 | 46 |
| 915 | 47 Much general information is in INSTALL. If it's covered in |
| 48 INSTALL, we don't repeat it here. | |
| 49 | |
| 3404 | 50 *** X11/bitmaps/gray (or other X11-related file) not found. |
| 51 | |
| 52 The X11R6 distribution was monolithic, but the X11R7 distribution is | |
| 53 much more modular. Many OS distributions omit these bitmaps (assuming | |
| 54 nobody uses them, evidently). Your OS distribution should have a | |
| 55 developer's package containing these files, probably with a name | |
| 56 containing the string "bitmap". Known package names (you may need to | |
| 57 add an extension such as .deb or .rpm) include x11/xbitmaps (Ubuntu) | |
| 58 and xorg-x11-xbitmaps (Fedora Core 5). | |
| 59 | |
| 1098 | 60 *** How do I configure to get the buffer tabs/progress bars? |
| 915 | 61 |
| 62 These features depend on support for "native widgets". Use the | |
|
4842
1d775c6304d1
Use with-FOO consistently instead of enable-FOO
Ben Wing <ben@xemacs.org>
parents:
4753
diff
changeset
|
63 --with-widgets option to configure. Configuration of widgets is |
| 915 | 64 automatic for "modern" toolkits (MS Windows, GTK, and Motif), but if |
| 65 you are using Xt and the Athena widgets, you will probably want to | |
| 66 specify a "3d" widget set. See configure --usage, and don't forget to | |
| 67 install the corresponding development libraries. | |
| 68 | |
| 69 *** I know I have libfoo installed, but configure doesn't find it. | |
| 70 | |
| 71 Typical of Linux systems with package managers. To link with a shared | |
| 72 library, you only need the shared library. To compile objects that | |
| 73 link with it, you need the headers---and distros don't provide them with | |
| 74 the libraries. You need the additional "development" package, too. | |
| 75 | |
| 373 | 76 *** When using gcc, you get the error message "undefined symbol __fixunsdfsi". |
| 77 When using gcc, you get the error message "undefined symbol __main". | |
| 78 | |
| 79 This means that you need to link with the gcc library. It may be called | |
| 80 "gcc-gnulib" or "libgcc.a"; figure out where it is, and define LIB_GCC in | |
| 81 config.h to point to it. | |
| 82 | |
| 83 It may also work to use the GCC version of `ld' instead of the standard one. | |
| 84 | |
| 85 *** Excessive optimization with pgcc can break XEmacs | |
| 124 | 86 |
| 87 It has been reported on some systems that compiling with -O6 can lead | |
| 88 to XEmacs failures. The workaround is to use a lower optimization | |
| 89 level. -O2 and -O4 have been tested extensively. | |
| 90 | |
| 229 | 91 All of this depends heavily on the version of pgcc and the version |
| 92 of libc. Snapshots near the release of pgcc-1.0 have been tested | |
| 93 extensively and no sign of breakage has been seen on systems using | |
| 94 glibc-2. | |
| 95 | |
| 373 | 96 *** src/Makefile and lib-src/Makefile are truncated--most of the file missing. |
| 229 | 97 |
| 373 | 98 This can happen if configure uses GNU sed version 2.03. That version |
| 99 had a bug. GNU sed version 2.05 works properly. | |
| 124 | 100 |
| 373 | 101 *** When compiling with X11, you get "undefined symbol _XtStrings". |
| 124 | 102 |
| 373 | 103 This means that you are trying to link emacs against the X11r4 version of |
| 104 libXt.a, but you have compiled either Emacs or the code in the lwlib | |
| 105 subdirectory with the X11r5 header files. That doesn't work. | |
| 124 | 106 |
| 373 | 107 Remember, you can't compile lwlib for r4 and emacs for r5, or vice versa. |
| 108 They must be in sync. | |
| 124 | 109 |
| 373 | 110 *** test-distrib says that the distribution has been clobbered |
| 197 | 111 or, temacs prints "Command key out of range 0-127" |
| 112 or, temacs runs and dumps xemacs, but xemacs totally fails to work. | |
| 113 or, temacs gets errors dumping xemacs | |
| 114 | |
| 115 This can be because the .elc files have been garbled. Do not be | |
| 116 fooled by the fact that most of a .elc file is text: these are binary | |
| 117 files and can contain all 256 byte values. | |
| 118 | |
| 119 In particular `shar' cannot be used for transmitting GNU Emacs. It | |
| 120 typically truncates "lines". (this does not apply to GNU shar, which | |
| 121 uses uuencode to encode binary files.) | |
| 122 | |
| 123 If you have a copy of Emacs that has been damaged in its nonprinting | |
| 124 characters, you can fix them by running: | |
| 125 | |
| 126 make all-elc | |
| 127 | |
| 128 This will rebuild all the needed .elc files. | |
| 129 | |
| 1318 | 130 ** Intel Architecture General |
| 131 | |
| 132 *** Don't use -O2 or -O3 with Cygwin 1.0, CodeFusion-99070 or gcc 2.7.2 on x86 | |
| 133 without also using `-fno-strength-reduce'. | |
| 134 | |
| 135 gcc will generate incorrect code otherwise. This bug is present in at | |
| 136 least 2.6.x and 2.7.[0-2]. This bug has been fixed in GCC 2.7.2.1 and | |
| 137 later. This bug is O/S independent, but is limited to x86 architectures. | |
| 138 | |
| 139 This problem is known to be fixed in egcs (or pgcc) 1.0 or later. | |
| 140 | |
| 141 Unfortunately, later releases of Cygnus-released compilers (not the | |
| 142 Net-released ones) have a bug with the same `problem signature'. | |
| 143 | |
| 144 If you're lucky, you'll get an error while compiling that looks like: | |
| 145 | |
| 146 event-stream.c:3189: internal error--unrecognizable insn: | |
| 147 (insn 256 14 15 (set (reg/v:SI 24) | |
| 148 (minus:SI (reg/v:SI 25) | |
| 149 (const_int 2))) -1 (insn_list 11 (nil)) | |
| 150 (nil)) | |
| 151 0 0 [main] | |
| 152 | |
| 153 If you're unlucky, your code will simply execute incorrectly. | |
| 154 | |
| 155 *** Don't use -O2 with gcc 2.7.2 under Intel architectures without also | |
| 156 using `-fno-caller-saves'. | |
| 157 | |
| 158 gcc will generate incorrect code otherwise. This bug is still | |
| 159 present in gcc 2.7.2.3. There have been no reports to indicate the | |
| 160 bug is present in egcs 1.0 (or pgcc 1.0) or later. This bug is O/S | |
| 161 independent, but limited to x86 architectures. | |
| 162 | |
| 163 This problem is known to be fixed in egcs (or pgcc) 1.0 or later. | |
| 164 | |
| 373 | 165 *** `compress' and `uncompress' not found and XFree86 |
| 166 | |
| 167 XFree86 installs a very old version of libz.a by default ahead of where | |
| 168 more modern version of libz might be installed. This will cause problems | |
| 169 when attempting to link against libMagick. The fix is to remove the old | |
| 170 libz.a in the X11 binary directory. | |
| 171 | |
| 172 | |
| 3863 | 173 ** X11 and Motif |
| 1245 | 174 |
| 175 Motif is the X11 version of the Gnus torture test: if there's a way to | |
| 176 crash, Motif will find it. With the open source release of Motif, it | |
| 177 seems like a good idea to collect all Motif-related issues in one | |
| 3863 | 178 place. X11 itself is not all that safe, either. |
| 179 | |
| 180 You should also look in your OS's section, as it may not be the window | |
| 181 system (toolkit's) fault. | |
| 182 | |
| 183 *** XEmacs and the X server crash when inserting or displaying a TAB character. | |
| 184 | |
| 185 If you are using the XFree86 distribution, you need an X server with | |
| 186 this patch applied: | |
| 187 | |
| 188 https://bugs.freedesktop.org/attachment.cgi?id=2016 | |
| 189 | |
| 190 Versions of XFree86 previous to that crashed when an app tried to draw a | |
| 191 literal tab character using many fonts. | |
| 1245 | 192 |
| 193 *** XEmacs crashes on exit (#1). | |
| 194 | |
| 195 The backtrace is something like: | |
| 196 | |
| 197 (gdb) where | |
| 198 #0 0xfeb9a480 in _libc_kill () from /usr/lib/libc.so.1 | |
| 199 #1 0x000b0388 in fatal_error_signal () | |
| 200 #2 <signal handler called> | |
| 201 #3 YowIter (ht=0xb, id=0x0, v=0x74682074, client=0x47e3c0) | |
| 202 at ImageCache.c:1159 | |
| 203 #4 0xff26cc5c in _LTHashTableForEachItem (ht=0x4725e8, | |
| 204 iter=0xff26dda0 <YowIter>, ClientData=0x47e3c0) at Hash.c:671 | |
| 205 #5 0xff2a4664 in destroy (w=0x496550) at Screen.c:352 | |
| 206 #6 0xfef92118 in Phase2Destroy () from /usr/openwin/lib/libXt.so.4 | |
| 207 #7 0xfef91940 in Recursive () from /usr/openwin/lib/libXt.so.4 | |
| 208 #8 0xfef91e44 in XtPhase2Destroy () from /usr/openwin/lib/libXt.so.4 | |
| 209 #9 0xfef91ae8 in _XtDoPhase2Destroy () from /usr/openwin/lib/libXt.so.4 | |
| 210 #10 0xfef918cc in XtDestroyWidget () from /usr/openwin/lib/libXt.so.4 | |
| 211 #11 0xfef91438 in CloseDisplay () from /usr/openwin/lib/libXt.so.4 | |
| 212 #12 0xfef91394 in XtCloseDisplay () from /usr/openwin/lib/libXt.so.4 | |
| 213 #13 0x0025b8b0 in x_delete_device () | |
| 214 #14 0x000940b0 in delete_device_internal () | |
| 215 #15 0x000806a0 in delete_console_internal () | |
| 216 | |
| 217 This is known to happen with Lesstif version 0.93.36. Similar | |
| 218 backtraces have also been observed on HP/UX and Solaris. There is a | |
| 219 patch for Lesstif. (This is not a solution; it just stops the crash. | |
| 220 It may or may not be harmless, but "it works for the author".) | |
| 221 | |
| 222 Note that this backtrace looks a lot like the one in the next item. | |
| 223 However, this one is invulnerable to the Solaris patches mentioned there. | |
| 224 | |
| 225 Frank McIngvale <frankm@hiwaay.net> says: | |
| 226 | |
| 227 Ok, 0.93.34 works, and I tracked down the crash to a section | |
| 228 marked "experimental" in 0.93.36. Patch attached, "works for me". | |
| 229 | |
| 230 diff -u -r lesstif-0.93.36/lib/Xm/ImageCache.c lesstif-0.93.36-mod/lib/Xm/ImageCache.c | |
| 231 --- lesstif-0.93.36/lib/Xm/ImageCache.c 2002-08-05 14:53:24.000000000 -0500 | |
| 232 +++ lesstif-0.93.36-mod/lib/Xm/ImageCache.c 2002-11-11 11:13:12.000000000 -0600 | |
| 233 @@ -1166,5 +1166,4 @@ | |
| 234 DEBUGOUT(_LtDebug0(__FILE__, NULL, "_LtImageCacheScreenDestroy (XmGetPixmapByDepth) %p\n", | |
| 235 s)); | |
| 236 | |
| 237 - (void) _LTHashTableForEachItem(PixmapCache, YowIter, (XtPointer)s); | |
| 238 } | |
| 239 | |
| 240 *** XEmacs crashes on exit (#2) | |
| 241 | |
| 242 Especially frequent with multiple frames. Crashes that produce C | |
| 243 backtraces like this: | |
| 244 | |
| 245 #0 0xfec9a118 in _libc_kill () from /usr/lib/libc.so.1 | |
| 246 #1 0x77f48 in fatal_error_signal (sig=11) | |
| 247 at /codes/rpluim/xemacs-21.4/src/emacs.c:539 | |
| 248 #2 <signal handler called> | |
| 249 #3 0xfee929f4 in XFindContext () from /usr/openwin/lib/libX11.so.4 | |
| 250 #4 0xfee92930 in XFindContext () from /usr/openwin/lib/libX11.so.4 | |
| 251 #5 0xff297e54 in DisplayDestroy () from /usr/dt/lib/libXm.so.4 | |
| 252 #6 0xfefbece0 in XtCallCallbackList () from /usr/openwin/lib/libXt.so.4 | |
| 253 #7 0xfefc486c in XtPhase2Destroy () from /usr/openwin/lib/libXt.so.4 | |
| 254 #8 0xfefc45d0 in _XtDoPhase2Destroy () from /usr/openwin/lib/libXt.so.4 | |
| 255 #9 0xfefc43b4 in XtDestroyWidget () from /usr/openwin/lib/libXt.so.4 | |
| 256 #10 0x15cf9c in x_delete_device (d=0x523f00) | |
| 257 | |
| 258 are caused by buggy Motif libraries. Installing the following patches | |
| 259 has been reported to solve the problem on Solaris 2.7: | |
| 260 | |
| 261 107081-40 107656-07 | |
| 262 | |
| 263 For information (although they have not been confirmed to work), the | |
| 264 equivalent patches for Solaris 2.8 are: | |
| 265 | |
| 266 108940-33 108652-25 | |
| 267 | |
| 268 *** On HP-UX 11.0 XEmacs causes excessive X11 errors when running. | |
| 269 (also appears on AIX as reported in comp.emacs.xemacs) | |
| 270 | |
| 271 Marcus Thiessel <marcus@xemacs.org> | |
| 272 | |
| 273 Unfortunately, XEmacs releases prior to 21.0 don't work with | |
| 274 Motif2.1. It will compile but you will get excessive X11 errors like | |
| 275 | |
| 276 xemacs: X Error of failed request: BadGC (invalid GC parameter) | |
| 277 | |
| 278 and finally XEmacs gets killed. A workaround is to use the | |
| 279 Motif1.2_R6 libraries. You can the following line to your call to | |
| 280 configure: | |
| 281 | |
| 282 --x-libraries="/usr/lib/Motif1.2_R6 -L/usr/lib/X11R6" | |
| 283 | |
| 284 Make sure /usr/lib/Motif1.2_R6/libXm.sl is a link to | |
| 285 /usr/lib/Motif1.2_R6/libXm.3. | |
| 286 | |
| 287 *** On HP-UX 11.0: Object "" does not have windowed ancestor | |
| 288 | |
| 289 Marcus Thiessel <marcus@xemacs.org> | |
| 290 | |
| 291 XEmacs dies without core file and reports: | |
| 292 | |
| 293 Error: Object "" does not have windowed ancestor. | |
| 294 | |
| 295 This is a bug. Please apply the patch PHSS_19964 (check if | |
| 296 superseded). The other alternative is to link with Motif1.2_R6 (see | |
| 297 previous item). | |
| 298 | |
| 299 *** Motif dialog boxes lose on Irix. | |
| 300 | |
| 301 Larry Auton <lda@control.att.com> writes: | |
| 302 Beware of not specifying | |
| 303 | |
|
4842
1d775c6304d1
Use with-FOO consistently instead of enable-FOO
Ben Wing <ben@xemacs.org>
parents:
4753
diff
changeset
|
304 --with-dialogs=athena |
| 1245 | 305 |
| 306 if it builds with the motif dialogs [boom!] you're a dead man. | |
| 307 | |
| 308 | |
| 373 | 309 ** AIX |
| 1009 | 310 *** IBM compiler fails: "The character # is not a valid C source character." |
| 311 | |
| 312 Most recently observed in 21.5.9, due to USE_KKCC ifdefs (they just | |
| 313 happen to tickle the implementation). | |
| 314 | |
| 315 Valdis Kletnieks says: | |
| 316 | |
| 317 The problem is that IBM defines a *MACRO* called 'memcpy', and we | |
| 318 have stuck a #ifdef/#endif inside the macro call. As a workaround, | |
| 319 try adding '-U__STR__' to your CFLAGS - this will cause string.h to | |
| 320 not do a #define for strcpy() to __strcpy() - it uses this for | |
| 321 automatic inlining support. | |
| 322 | |
| 323 (For the record, the same issue affects a number of other functions | |
| 324 defined in string.h - basically anything the compiler knows how to | |
| 325 inline.) | |
| 326 | |
|
4842
1d775c6304d1
Use with-FOO consistently instead of enable-FOO
Ben Wing <ben@xemacs.org>
parents:
4753
diff
changeset
|
327 *** On AIX 4.3, you must specify --with-dialogs=athena with configure |
| 373 | 328 |
| 442 | 329 *** The libXt shipped with AIX 4.3 up to 4.3.2 is broken. This causes |
| 330 xemacs -nw to fail in various ways. The official APAR is this: | |
| 331 | |
| 332 APAR NUMBER: <IX89470> RESOLVED AS: PROGRAM ERROR | |
| 333 | |
| 334 ABSTRACT: | |
| 335 <IX89470>: LIBXT.A INCORRECT HANDLING OF EXCEPTIONS IN XTAPPADDINPUT | |
| 336 | |
| 337 The solution is to install X11.base.lib at version >=4.3.2.5. | |
| 392 | 338 |
| 373 | 339 *** On AIX, you get this compiler error message: |
| 340 | |
| 341 Processing include file ./XMenuInt.h | |
| 342 1501-106: (S) Include file X11/Xlib.h not found. | |
| 343 | |
| 344 This means your system was installed with only the X11 runtime i.d | |
| 345 libraries. You have to find your sipo (bootable tape) and install | |
| 346 X11Dev... with smit. | |
| 347 | |
| 348 *** On AIX 4.1.2, linker error messages such as | |
| 349 ld: 0711-212 SEVERE ERROR: Symbol .__quous, found in the global symbol table | |
| 350 of archive /usr/lib/libIM.a, was not defined in archive member shr.o. | |
| 351 | |
| 352 This is a problem in libIM.a. You can work around it by executing | |
| 353 these shell commands in the src subdirectory of the directory where | |
| 354 you build Emacs: | |
| 355 | |
| 356 cp /usr/lib/libIM.a . | |
| 357 chmod 664 libIM.a | |
| 358 ranlib libIM.a | |
| 359 | |
| 360 Then change -lIM to ./libIM.a in the command to link temacs (in | |
| 361 Makefile). | |
| 362 | |
| 363 *** Excessive optimization on AIX 4.2 can lead to compiler failure. | |
| 364 | |
| 365 Valdis.Kletnieks@vt.edu writes: | |
| 366 At least at the b34 level, and the latest-and-greatest IBM xlc | |
| 367 (3.1.4.4), there are problems with -O3. I haven't investigated | |
| 368 further. | |
| 369 | |
| 370 | |
| 371 ** SunOS/Solaris | |
| 1318 | 372 *** Don't use -O2 with gcc 2.8.1 and egcs 1.0 under SPARC architectures |
| 373 without also using `-fno-schedule-insns'. | |
| 374 | |
| 375 gcc will generate incorrect code otherwise, typically resulting in | |
| 376 crashes in the function skip-syntax-backward. | |
| 377 | |
| 378 *** Don't use gcc-2.95.2 with -mcpu=ultrasparc on Solaris 2.6. | |
| 379 | |
| 380 gcc will assume a 64-bit operating system, even though you've | |
| 381 merely told it to assume a 64-bit instruction set. | |
| 382 | |
| 454 | 383 *** Dumping error when using GNU binutils / GNU ld on a Sun. |
| 384 | |
| 385 Errors similar to the following: | |
| 386 | |
| 387 Dumping under the name xemacs unexec(): | |
| 388 dldump(/space/rpluim/xemacs-obj/src/xemacs): ld.so.1: ./temacs: | |
| 389 fatal: /space/rpluim/xemacs-obj/src/xemacs: unknown dynamic entry: | |
| 390 1879048176 | |
| 391 | |
| 392 are caused by using GNU ld. There are several workarounds available: | |
| 393 | |
| 394 In XEmacs 21.2 or later, configure using the new portable dumper | |
|
4842
1d775c6304d1
Use with-FOO consistently instead of enable-FOO
Ben Wing <ben@xemacs.org>
parents:
4753
diff
changeset
|
395 (--with-pdump). |
| 454 | 396 |
| 397 Alternatively, you can link using the Sun version of ld, which is | |
| 398 normally held in /usr/ccs/bin. This can be done by one of: | |
| 399 | |
| 400 - building gcc with these configure flags: | |
| 401 configure --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as | |
| 402 | |
| 403 - adding -B/usr/ccs/bin/ to CFLAGS used to configure XEmacs | |
| 404 (Note: The trailing '/' there is significant.) | |
| 405 | |
| 406 - uninstalling GNU ld. | |
| 407 | |
| 408 The Solaris2 FAQ claims: | |
| 409 | |
| 410 When you install gcc, don't make the mistake of installing | |
| 411 GNU binutils or GNU libc, they are not as capable as their | |
| 412 counterparts you get with Solaris 2.x. | |
| 413 | |
| 373 | 414 *** Link failure when using acc on a Sun. |
| 415 | |
| 416 To use acc, you need additional options just before the libraries, such as | |
| 417 | |
| 418 /usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1 | |
| 419 | |
| 420 and you need to add -lansi just before -lc. | |
| 421 | |
| 422 The precise file names depend on the compiler version, so we | |
| 423 cannot easily arrange to supply them. | |
| 424 | |
| 425 *** Problems finding X11 libraries on Solaris with Openwindows | |
| 426 | |
| 427 Some users have reported problems in this area. The reported solution | |
| 428 is to define the environment variable OPENWINHOME, even if you must set | |
| 429 it to `/usr/openwin'. | |
| 430 | |
| 431 *** Sed problems on Solaris 2.5 | |
| 432 | |
| 433 There have been reports of Sun sed truncating very lines in the | |
| 434 Makefile during configuration. The workaround is to use GNU sed or, | |
| 454 | 435 even better, think of a better way to generate Makefile, and send us a |
| 373 | 436 patch. :-) |
| 437 | |
| 438 *** On Solaris 2 I get undefined symbols from libcurses.a. | |
| 439 | |
| 440 You probably have /usr/ucblib/ on your LD_LIBRARY_PATH. Do the link with | |
| 441 LD_LIBRARY_PATH unset. Generally, avoid using any ucb* stuff when | |
| 442 building XEmacs. | |
| 443 | |
| 444 *** On Solaris 2 I cannot make alloc.o, glyphs.o or process.o. | |
| 445 | |
| 446 The SparcWorks C compiler may have difficulty building those modules | |
| 447 with optimization level -xO4. Try using only "-fast" optimization | |
| 448 for just those modules. (Or use gcc). | |
| 449 | |
| 450 *** Solaris 2.3 /bin/sh coredumps during configuration. | |
| 451 | |
| 452 This only occurs if you have LANG != C. This is a known bug with | |
| 453 /bin/sh fixed by installing Patch-ID# 101613-01. Or, you can use | |
| 1697 | 454 bash by setting the environment variable CONFIG_SHELL to /bin/bash |
| 455 | |
| 456 *** Solaris 2.x configure fails: ./config.status: test: argument expected | |
| 457 | |
| 458 This is a known bug with /bin/sh and /bin/test, i.e. they do not | |
| 459 support the XPG4 standard. You can use bash as a workaround or an | |
| 460 XPG4-compliant Bourne shell such as the Sun-supplied /usr/xpg4/bin/sh | |
| 461 by setting the environment variable CONFIG_SHELL to /usr/xpg4/bin/sh | |
| 373 | 462 |
| 463 *** On SunOS, you get linker errors | |
| 454 | 464 ld: Undefined symbol |
| 373 | 465 _get_wmShellWidgetClass |
| 466 _get_applicationShellWidgetClass | |
| 467 | |
| 468 The fix to this is to install patch 100573 for OpenWindows 3.0 | |
| 469 or link libXmu statically. | |
| 470 | |
| 471 *** On Sunos 4, you get the error ld: Undefined symbol __lib_version. | |
| 472 | |
| 473 This is the result of using cc or gcc with the shared library meant | |
| 474 for acc (the Sunpro compiler). Check your LD_LIBRARY_PATH and delete | |
| 475 /usr/lang/SC2.0.1 or some similar directory. | |
| 476 | |
| 477 *** Undefined symbols when linking on Sunos 4.1. | |
| 478 | |
| 479 If you get the undefined symbols _atowc _wcslen, _iswprint, _iswspace, | |
| 480 _iswcntrl, _wcscpy, and _wcsncpy, then you need to add -lXwchar after | |
| 481 -lXaw in the command that links temacs. | |
| 482 | |
| 483 This problem seems to arise only when the international language | |
| 484 extensions to X11R5 are installed. | |
| 485 | |
| 486 *** On a Sun running SunOS 4.1.1, you get this error message from GNU ld: | |
| 487 | |
| 454 | 488 /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment |
| 373 | 489 |
| 490 The problem is in the Sun shared C library, not in GNU ld. | |
| 491 | |
| 492 The solution is to install Patch-ID# 100267-03 from Sun. | |
| 493 | |
| 494 *** SunOS 4.1.2: undefined symbol _get_wmShellWidgetClass | |
| 495 | |
| 496 Apparently the version of libXmu.so.a that Sun ships is hosed: it's missing | |
| 454 | 497 some stuff that is in libXmu.a (the static version). Sun has a patch for |
| 373 | 498 this, but a workaround is to use the static version of libXmu, by changing |
| 499 the link command from "-lXmu" to "-Bstatic -lXmu -Bdynamic". If you have | |
| 500 OpenWindows 3.0, ask Sun for these patches: | |
| 501 100512-02 4.1.x OpenWindows 3.0 libXt Jumbo patch | |
| 502 100573-03 4.1.x OpenWindows 3.0 undefined symbols with shared libXmu | |
| 503 | |
| 504 *** Random other SunOS 4.1.[12] link errors. | |
| 505 | |
| 506 The X headers and libraries that Sun ships in /usr/{include,lib}/X11 are | |
| 507 broken. Use the ones in /usr/openwin/{include,lib} instead. | |
| 508 | |
| 509 ** Linux | |
| 1318 | 510 |
| 511 See also Intel Architecture General, above. | |
| 512 | |
| 513 *** egcs-1.1 on Alpha Linux | |
| 514 | |
| 515 There have been reports of egcs-1.1 not compiling XEmacs correctly on | |
| 516 Alpha Linux. There have also been reports that egcs-1.0.3a is O.K. | |
| 517 | |
| 373 | 518 *** Under Linux, you get "too many arguments to function `getpgrp'". |
| 519 | |
| 520 You have probably installed LessTiff under `/usr/local' and `libXm.so' | |
| 521 could not be found when linking `getpgrp()' test program, making XEmacs | |
| 522 think that `getpgrp()' takes an argument. Try adding `/usr/local/lib' | |
| 523 in `/etc/ld.so.conf' and run `ldconfig'. Then run XEmacs's `configure' | |
| 524 again. As with all problems of this type, reading the config.log file | |
| 525 generated from configure and seeing the log of how the test failed can | |
| 526 prove enlightening. | |
| 527 | |
| 528 *** `Error: No ExtNode to pop!' on Linux systems with Lesstif. | |
| 197 | 529 |
| 530 This error message has been observed with lesstif-0.75a. It does not | |
| 531 appear to cause any harm. | |
| 532 | |
| 373 | 533 *** xemacs: can't resolve symbol '__malloc_hook' |
| 534 | |
| 535 This is a Linux problem where you've compiled the XEmacs binary on a libc | |
| 536 5.4 with version higher than 5.4.19 and attempted to run the binary against | |
| 537 an earlier version. The solution is to upgrade your old library. | |
| 538 | |
| 539 ** IRIX | |
| 452 | 540 |
| 1098 | 541 *** More coredumping in Irix (6.5 known to be vulnerable) |
| 542 | |
| 543 No fix is known yet. Here's the best information we have: | |
| 544 | |
| 545 Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes: | |
| 546 | |
| 547 Were xemacs and [any 3rd party, locally-compiled] libraries [you use] | |
| 548 all compiled with the same ABI ( -o32, -n32, -64) and | |
| 549 mips2/mips3/mips4 flags, and are they appropriate for the machine in | |
| 550 question? I know the IP30 implies an Octane, so it should be an R10K | |
| 551 chipset and above such nonsense, but I've seen the most astoundingly | |
| 552 bizzare crashes when somebody managed to compile with -mips4 and get | |
| 553 it to run on an R4400 or R5K system. ;) | |
| 554 | |
| 555 Also, since you're using gcc, try re-running fixincludes and *then* | |
| 556 rebuilding xemacs and [any] libraries - mismatched headers can do that | |
| 557 sort of thing to you with little or no clue what's wrong (often you | |
| 558 get screwed when one routine does an malloc(sizeof(foo_struct)) and | |
| 559 passes the result to something that things foo_struct is a bit bigger, | |
| 560 trashing memory.... | |
| 561 | |
|
4842
1d775c6304d1
Use with-FOO consistently instead of enable-FOO
Ben Wing <ben@xemacs.org>
parents:
4753
diff
changeset
|
562 Here's typical crash backtrace. With --with-pdump, this occurs |
| 2648 | 563 usually at startup under X windows and xemacs -nw at least starts, while |
| 564 without --pdump a similar crash is observed during build. | |
| 1098 | 565 |
| 566 #0 0x0fa460b8 in kill () at regcomp.c:637 | |
| 567 637 regcomp.c: No such file or directory. | |
| 568 in regcomp.c | |
| 569 (gdb) where | |
| 570 #0 0x0fa460b8 in kill () at regcomp.c:637 | |
| 571 #1 0x10087f34 in fatal_error_signal () | |
| 572 (gdb) quit | |
| 573 | |
| 574 This is confusing because there is no such file in the XEmacs | |
| 575 distribution. This is seen on (at least) the following configurations: | |
| 576 | |
| 577 uname -a: IRIX64 oct202 6.5 01091821 IP30 | |
| 578 XEmacs 21.4.9 "Informed Management" configured for `mips-sgi-irix6.5'. | |
| 579 XEmacs 21.5-b9 "brussels sprouts" configured for `mips-sgi-irix6.5'. | |
| 580 | |
| 452 | 581 *** On Irix 6.5, the MIPSpro compiler gets an internal compiler error |
| 582 | |
| 583 The MIPSpro Compiler (at least version 7.2.1) can't seem to handle the | |
| 584 union type properly, and fails to compile src/glyphs.c. To avoid this | |
|
4842
1d775c6304d1
Use with-FOO consistently instead of enable-FOO
Ben Wing <ben@xemacs.org>
parents:
4753
diff
changeset
|
585 problem, always build --with-union-type=no (but that's the default, so |
| 452 | 586 you should only see this problem if you're an XEmacs maintainer). |
| 587 | |
| 373 | 588 *** Linking with -rpath on IRIX. |
| 124 | 589 |
| 590 Darrell Kindred <dkindred@cmu.edu> writes: | |
| 591 There are a couple of problems [with use of -rpath with Irix ld], though: | |
| 592 | |
| 593 1. The ld in IRIX 5.3 ignores all but the last -rpath | |
| 594 spec, so the patched configure spits out a warning | |
| 2648 | 595 if --x-libraries or --with-site-runtime-libraries are |
| 454 | 596 specified under irix 5.x, and it only adds -rpath |
| 2648 | 597 entries for the --with-site-runtime-libraries. This bug was |
| 124 | 598 fixed sometime between 5.3 and 6.2. |
| 599 | |
| 600 2. IRIX gcc 2.7.2 doesn't accept -rpath directly, so | |
| 601 it would have to be prefixed by -Xlinker or "-Wl,". | |
| 602 This would be fine, except that configure compiles with | |
| 603 ${CC-cc} $CFLAGS $LDFLAGS ... | |
| 604 rather than quoting $LDFLAGS with prefix-args, like | |
| 605 src/Makefile does. So if you specify --x-libraries | |
| 2648 | 606 or --with-site-runtime-libraries, you must use |
| 607 --with--gcc=no, or configure will fail. | |
| 124 | 608 |
| 373 | 609 *** On Irix 6.3, the SGI ld quits with segmentation fault when linking temacs |
| 207 | 610 |
| 611 This occurs if you use the SGI linker version 7.1. Installing the | |
| 612 patch SG0001872 fixes this problem. | |
| 197 | 613 |
| 373 | 614 *** On Irix 6.0, make tries (and fails) to build a program named unexelfsgi |
| 615 | |
| 616 A compiler bug inserts spaces into the string "unexelfsgi . o" | |
| 617 in src/Makefile. Edit src/Makefile, after configure is run, | |
| 618 find that string, and take out the spaces. | |
| 619 | |
| 620 Compiler fixes in Irix 6.0.1 should eliminate this problem. | |
| 124 | 621 |
| 373 | 622 *** On Irix 5.2, unexelfsgi.c can't find cmplrs/stsupport.h. |
| 124 | 623 |
| 373 | 624 The file cmplrs/stsupport.h was included in the wrong file set in the |
| 625 Irix 5.2 distribution. You can find it in the optional fileset | |
| 626 compiler_dev, or copy it from some other Irix 5.2 system. A kludgy | |
| 627 workaround is to change unexelfsgi.c to include sym.h instead of | |
| 628 syms.h. | |
| 124 | 629 |
| 373 | 630 *** Coredumping in Irix 6.2 |
| 124 | 631 |
| 373 | 632 Pete Forman <gsez020@compo.bedford.waii.com> writes: |
| 633 A problem noted by myself and others (I've lost the references) was | |
| 634 that XEmacs coredumped when the cut or copy toolbar buttons were | |
| 635 pressed. This has been fixed by loading the SGI patchset (Feb 98) | |
| 636 without having to recompile XEmacs. | |
| 124 | 637 |
| 373 | 638 My versions are XEmacs 20.3 (problem first noted in 19.15) and IRIX |
| 639 6.2, compiled using -n32. I'd guess that the relevant individual | |
| 640 patch was "SG0002580: multiple fixes for X libraries". SGI recommends | |
| 641 that the complete patch set be installed rather than parts of it. | |
| 124 | 642 |
| 373 | 643 ** Digital UNIX/OSF/VMS |
| 644 *** On Digital UNIX, the DEC C compiler might have a problem compiling | |
| 197 | 645 some files. |
| 124 | 646 |
| 647 In particular, src/extents.c and src/faces.c might cause the DEC C | |
| 648 compiler to abort. When this happens: cd src, compile the files by | |
| 649 hand, cd .., and redo the "make" command. When recompiling the files by | |
| 650 hand, use the old C compiler for the following versions of Digital UNIX: | |
| 651 - V3.n: Remove "-migrate" from the compile command. | |
| 652 - V4.n: Add "-oldc" to the compile command. | |
| 653 | |
| 197 | 654 A related compiler bug has been fixed by the DEC compiler team. The |
| 655 new versions of the compiler should run fine. | |
| 126 | 656 |
| 373 | 657 *** Under some versions of OSF XEmacs runs fine if built without |
| 658 optimization but will crash randomly if built with optimization. | |
| 659 | |
| 660 Using 'cc -g' is not sufficient to eliminate all optimization. Try | |
| 661 'cc -g -O0' instead. | |
| 662 | |
| 663 *** Compilation errors on VMS. | |
| 664 | |
| 665 Sorry, XEmacs does not work under VMS. You might consider working on | |
| 666 the port if you really want to have XEmacs work under VMS. | |
| 667 | |
| 668 ** HP-UX | |
| 669 *** On HPUX, the HP C compiler might have a problem compiling some files | |
| 278 | 670 with optimization. |
| 124 | 671 |
| 672 Richard Cognot <cognot@ensg.u-nancy.fr> writes: | |
| 673 | |
| 674 Had to drop once again to level 2 optimization, at least to | |
| 675 compile lstream.c. Otherwise, I get a "variable is void: \if" | |
| 676 problem while dumping (this is a problem I already reported | |
| 677 with vanilla hpux 10.01 and 9.07, which went away after | |
| 678 applying patches for the C compiler). Trouble is I still | |
| 679 haven't found the same patch for hpux 10.10, and I don't | |
| 680 remember the patch numbers. I think potential XEmacs builders | |
| 681 on HP should be warned about this. | |
| 682 | |
| 373 | 683 *** I don't have `xmkmf' and `imake' on my HP. |
| 124 | 684 |
| 304 | 685 You can get these standard X tools by anonymous FTP to |
| 686 hpcvaaz.cv.hp.com. Essentially all X programs need these. | |
| 124 | 687 |
| 373 | 688 *** On HP-UX, problems with make |
| 278 | 689 |
| 442 | 690 Marcus Thiessel <marcus@xemacs.org> |
| 278 | 691 |
| 304 | 692 Some releases of XEmacs (e.g. 20.4) require GNU make to build |
| 693 successfully. You don't need GNU make when building 21.x. | |
| 278 | 694 |
| 373 | 695 *** On HP-UX 9.05 XEmacs won't compile or coredump during the build. |
| 278 | 696 |
| 442 | 697 Marcus Thiessel <marcus@xemacs.org> |
| 278 | 698 |
| 699 This might be a sed problem. For your own safety make sure to use | |
| 700 GNU sed while dumping XEmacs. | |
| 701 | |
| 442 | 702 |
| 373 | 703 ** SCO OpenServer |
| 704 *** Native cc on SCO OpenServer 5 is now OK. Icc may still throw you | |
| 197 | 705 a curve. Here is what Robert Lipe <robertl@arnet.com> says: |
| 124 | 706 |
| 454 | 707 Unlike XEmacs 19.13, building with the native cc on SCO OpenServer 5 |
| 124 | 708 now produces a functional binary. I will typically build this |
| 709 configuration for COFF with: | |
| 710 | |
| 197 | 711 /path_to_xemacs_source/configure --with-gcc=no \ |
| 2648 | 712 --with-site-includes=/usr/local/include \ |
| 713 --with-site-libraries=/usr/local/lib \ | |
|
4842
1d775c6304d1
Use with-FOO consistently instead of enable-FOO
Ben Wing <ben@xemacs.org>
parents:
4753
diff
changeset
|
714 --with-xpm --with-xface --with-sound=nas |
| 124 | 715 |
| 454 | 716 This version now supports ELF builds. I highly recommend this to |
| 717 reduce the in-core footprint of XEmacs. This is now how I compile | |
| 124 | 718 all my test releases. Build it like this: |
| 719 | |
| 720 /path_to_XEmacs_source/configure --with-gcc=no \ | |
| 2648 | 721 --with-site-includes=/usr/local/include |
| 722 --with-site-libraries=/usr/local/lib \ | |
|
4842
1d775c6304d1
Use with-FOO consistently instead of enable-FOO
Ben Wing <ben@xemacs.org>
parents:
4753
diff
changeset
|
723 --with-xpm --with-xface --with-sound=nas --with-dynamic |
| 124 | 724 |
| 454 | 725 The compiler known as icc [ supplied with the OpenServer 5 Development |
| 124 | 726 System ] generates a working binary, but it takes forever to generate |
| 727 XEmacs. ICC also whines more about the code than /bin/cc does. I do | |
| 728 believe all its whining is legitimate, however. Note that you do | |
| 729 have to 'cd src ; make LD=icc' to avoid linker errors. | |
| 730 | |
| 731 The way I handle the build procedure is: | |
| 732 | |
| 733 /path_to_XEmacs_source/configure --with-gcc=no \ | |
| 2648 | 734 --with-site-includes=/usr/local/include \ |
| 735 --with-site-libraries=/usr/local/lib \ | |
|
4842
1d775c6304d1
Use with-FOO consistently instead of enable-FOO
Ben Wing <ben@xemacs.org>
parents:
4753
diff
changeset
|
736 --with-xpm --with-xface --with-sound=nas --with-dynamic \ |
| 2648 | 737 --with-compiler="icc" |
| 124 | 738 |
| 454 | 739 NOTE I have the xpm, xface, and audio libraries and includes in |
| 124 | 740 /usr/local/lib, /usr/local/include. If you don't have these, |
| 741 don't include the "--with-*" arguments in any of my examples. | |
| 742 | |
| 454 | 743 In previous versions of XEmacs, you had to override the defaults while |
| 124 | 744 compiling font-lock.o and extents.o when building with icc. This seems |
| 745 to no longer be true, but I'm including this old information in case it | |
| 746 resurfaces. The process I used was: | |
| 747 | |
| 454 | 748 make -k |
| 749 [ procure pizza, beer, repeat ] | |
| 124 | 750 cd src |
| 751 make CC="icc -W0,-mP1COPT_max_tree_size=3000" font-lock.o extents.o | |
| 752 make LD=icc | |
| 753 | |
| 454 | 754 If you want sound support, get the tls566 supplement from |
| 755 ftp.sco.com:/TLS or any of its mirrors. It works just groovy | |
| 124 | 756 with XEmacs. |
| 757 | |
| 758 The M-x manual-entry is known not to work. If you know Lisp and would | |
| 759 like help in making it work, e-mail me at <robertl@dgii.com>. | |
| 760 (UNCHECKED for 19.15 -- it might work). | |
| 761 | |
| 454 | 762 In earlier releases, gnuserv/gnuclient/gnudoit would open a frame |
| 124 | 763 just fine, but the client would lock up and the server would |
| 454 | 764 terminate when you used C-x # to close the frame. This is now |
| 124 | 765 fixed in XEmacs. |
| 766 | |
| 767 In etc/ there are two files of note. emacskeys.sco and emacsstrs.sco. | |
| 768 The comments at the top of emacskeys.sco describe its function, and | |
| 769 the emacstrs.sco is a suitable candidate for /usr/lib/keyboard/strings | |
| 770 to take advantage of the keyboard map in emacskeys.sco. | |
| 771 | |
| 373 | 772 Note: Much of the above entry is probably not valid for XEmacs 21.0 |
| 207 | 773 and later. |
| 197 | 774 |
| 1332 | 775 ** Windows |
| 776 | |
| 1441 | 777 *** XEmacs complains "No such file or directory, diff" |
| 778 | |
| 779 or "ispell" or other commands that seem related to whatever you just | |
| 780 tried to do. | |
| 781 | |
| 782 There are a large number of common (in the sense that "everyone has | |
| 783 these, really") Unix utilities that are not provided with XEmacs. The | |
| 784 GNU Project's implementations are available for Windows in the the | |
| 785 Cygwin distribution (http://www.cygwin.com/), which also provides a | |
| 786 complete Unix emulation environment (and thus makes ports of Unix | |
| 787 utilities nearly trivial). Another implementation is that from MinGW | |
| 788 (http://www.mingw.org/msys.shtml). | |
| 789 | |
| 1332 | 790 *** Weird crashes in pdump load or shortly after pdump load. |
| 791 | |
| 792 This can happen with incremental linking. Check if you have set | |
| 793 SUPPORT_EDIT_AND_CONTINUE to non-zero in config.inc, which must allow | |
| 794 incremental linking to be enabled (otherwise it's disabled). Either turn | |
| 795 this off, execute `nmake -f xemacs.mak clean', or manually remove | |
| 796 `temacs.exe' and `xemacs.exe'. | |
| 797 | |
| 392 | 798 ** Cygwin |
| 524 | 799 |
| 1318 | 800 See also Intel Architecture General, above. |
| 801 | |
| 802 *** Signal 11 when building or running a dumped XEmacs. | |
| 803 | |
|
4877
1a9c94ba117c
add issue about building on Cygwin with C++, NEWGC and optimization
Ben Wing <ben@xemacs.org>
parents:
4842
diff
changeset
|
804 Possibility #1: |
|
1a9c94ba117c
add issue about building on Cygwin with C++, NEWGC and optimization
Ben Wing <ben@xemacs.org>
parents:
4842
diff
changeset
|
805 |
| 1318 | 806 This appears to happen when using the traditional dumping mechanism and |
| 807 the system malloc. Andy Piper writes: | |
| 808 | |
| 1332 | 809 Traditional dumping on Cygwin relies on using gmalloc (there are specific |
| 1318 | 810 hacks in our version of gmalloc to support this), I suspect using sysmalloc |
| 811 is the problem. | |
| 812 | |
| 813 Try configuring with pdump or without system malloc. | |
| 814 | |
|
4877
1a9c94ba117c
add issue about building on Cygwin with C++, NEWGC and optimization
Ben Wing <ben@xemacs.org>
parents:
4842
diff
changeset
|
815 Possibility #2: |
|
1a9c94ba117c
add issue about building on Cygwin with C++, NEWGC and optimization
Ben Wing <ben@xemacs.org>
parents:
4842
diff
changeset
|
816 |
|
1a9c94ba117c
add issue about building on Cygwin with C++, NEWGC and optimization
Ben Wing <ben@xemacs.org>
parents:
4842
diff
changeset
|
817 Crashes when running a dumped XEmacs 21.5.29 have been observed circa |
|
1a9c94ba117c
add issue about building on Cygwin with C++, NEWGC and optimization
Ben Wing <ben@xemacs.org>
parents:
4842
diff
changeset
|
818 January, 2010 in Cygwin 1.7 when configuring with C++, NEWGC and optimization |
|
1a9c94ba117c
add issue about building on Cygwin with C++, NEWGC and optimization
Ben Wing <ben@xemacs.org>
parents:
4842
diff
changeset
|
819 (i.e. `--with-compiler=gcc --with-xemacs-compiler=g++ --with-mc-alloc |
|
1a9c94ba117c
add issue about building on Cygwin with C++, NEWGC and optimization
Ben Wing <ben@xemacs.org>
parents:
4842
diff
changeset
|
820 --with-optimization'). Turning any one of these off produces a working build. |
|
1a9c94ba117c
add issue about building on Cygwin with C++, NEWGC and optimization
Ben Wing <ben@xemacs.org>
parents:
4842
diff
changeset
|
821 |
| 524 | 822 *** Syntax errors running configure scripts, make failing with exit code 127 |
| 823 in inexplicable situations, etc. | |
| 392 | 824 |
| 1332 | 825 [[ This may be because you are using the default Cygwin shell, under old |
| 826 versions of Cygwin. The default Cygwin shell (/bin/sh.exe) is ash, which | |
| 827 appears to work in most circumstances but has some weird failure modes. | |
| 828 You may need to replace the symlink with bash.exe. ]] This doesn't appear | |
| 829 to affect Cygwin any longer, and /bin/sh.exe is no longer a symlink in | |
| 830 any case. | |
| 392 | 831 |
| 524 | 832 *** Lots of compile errors, esp. on lines containing macro definitions |
| 833 terminated by backslashes. | |
| 392 | 834 |
| 524 | 835 Your partition holding the source files is mounted binary. It needs |
| 836 to be mounted text. (This will not screw up any binary files because | |
| 837 the Cygwin utilities specify explicitly whether they want binary or | |
| 838 text mode when working with source vs. binary files, which overrides | |
| 839 the mount type.) To fix this, you just need to run the appropriate | |
| 840 mount command once -- afterwards, the settings are remembered in the | |
| 841 registry. | |
| 392 | 842 |
| 524 | 843 *** Errors from make like /c:not found. |
| 392 | 844 |
| 524 | 845 Make sure you set the environment variable MAKE_MODE to UNIX in your |
| 846 .bashrc, Control Panel (Windows 2000/NT), or AUTOEXEC.BAT (Windows | |
| 847 98/95). | |
| 392 | 848 |
| 849 *** The info files will not build. | |
| 850 | |
| 1332 | 851 makeinfo that ships with old versions of Cygwin doesn't work. |
| 852 Upgrade to the latest Cygwin version. | |
| 392 | 853 |
| 524 | 854 *** XEmacs hangs while attempting to rebuild the .elc files. |
| 392 | 855 |
| 524 | 856 Check to make sure you're not configuring with rel-alloc. The relocating |
| 857 allocator does not currently work under Cygwin due to bugs in Cygwin's | |
| 858 mmap(). | |
| 392 | 859 |
| 524 | 860 *** Trying to build with X, but X11 not detected. |
| 861 | |
| 862 This is usually because xmkmf is not in your path or because you are | |
| 1332 | 863 using the default Cygwin shell. (See above.) |
| 333 | 864 |
| 865 | |
| 373 | 866 * Problems with running XEmacs |
| 867 ============================== | |
| 868 ** General | |
| 1332 | 869 |
| 870 *** Changes made to .el files do not take effect. | |
| 871 | |
| 872 You may have forgotten to recompile them into .elc files. Then the | |
| 873 old .elc files will be loaded, and your changes will not be seen. To | |
| 874 fix this, do `M-x byte-recompile-directory' and specify the directory | |
| 875 that contains the Lisp files. | |
| 876 | |
| 877 Note that you will get a warning when loading a .elc file that is | |
| 878 older than the corresponding .el file. | |
| 879 | |
| 880 *** VM appears to hang in large folders. | |
| 881 | |
| 882 This is normal (trust us) when upgrading to VM-6.22 from earlier | |
| 883 versions. Let VM finish what it is doing and all will be well. | |
| 1042 | 884 |
| 892 | 885 *** Starting with 21.4.x, killing text is absurdly slow. |
| 886 | |
| 887 See FAQ Q3.10.6. Should be available on the web near | |
| 888 http://www.xemacs.org/faq/xemacs-faq.html#SEC160. | |
| 889 | |
| 835 | 890 *** Whenever I try to retrieve a remote file, I have problems. |
| 891 | |
| 892 A typical error: FTP Error: USER request failed; 500 AUTH not understood. | |
| 893 Thanks to giacomo boffi <giacomo.boffi@polimi.it> on comp.emacs.xemacs: | |
| 894 | |
| 895 tell your ftp client to not attempt AUTH authentication (or do not | |
| 896 use FTP servers that don't understand AUTH) | |
| 897 | |
| 898 and notes that you need to add an element (often "-u") to | |
| 899 `efs-ftp-program-args'. Use M-x customize-variable, and verify the | |
| 900 needed flag with `man ftp' or other local documentation. | |
| 901 | |
| 464 | 902 *** gnuserv is running, some clients can connect, but others cannot. |
| 903 | |
| 904 The code in gnuslib.c respects the value of TMPDIR. If the server and | |
| 905 the client have different values in their environment, you lose. | |
| 906 One program known to set TMPDIR and manifest this problem is exmh. | |
| 907 You can defeat the use of TMPDIR by unsetting USE_TMPDIR at the top of | |
| 908 gnuserv.h at build time. | |
| 909 | |
| 1332 | 910 ** General Unix |
| 124 | 911 |
| 373 | 912 *** You type Control-H (Backspace) expecting to delete characters. |
| 124 | 913 |
| 914 Emacs has traditionally used Control-H for help; unfortunately this | |
| 424 | 915 interferes with its use as Backspace on TTY's. As of XEmacs 21, |
| 916 XEmacs looks at the "erase" setting of TTY structures and maps C-h to | |
| 917 backspace when erase is set to C-h. This is sort of a special hack, | |
| 918 but it makes it possible for you to use the standard: | |
| 919 | |
| 920 stty erase ^H | |
| 355 | 921 |
| 424 | 922 to get your backspace key to erase characters. The erase setting is |
| 923 recorded in the Lisp variable `tty-erase-char', which you can use to | |
| 924 tune the settings in your .emacs. | |
| 124 | 925 |
| 424 | 926 A major drawback of this is that when C-h becomes backspace, it no |
| 927 longer invokes help. In that case, you need to use f1 for help, or | |
| 928 bind another key. An example of the latter is the following code, | |
| 929 which moves help to Meta-? (ESC ?): | |
| 124 | 930 |
| 424 | 931 (global-set-key "\M-?" 'help-command) |
| 124 | 932 |
| 1332 | 933 *** At startup I get a warning on stderr about missing charsets: |
| 934 | |
| 935 Warning: Missing charsets in String to FontSet conversion | |
| 936 | |
| 937 You need to specify appropriate charsets for your locale (usually the | |
| 938 value of the LANG environment variable) in .Xresources. See | |
| 939 etc/Emacs.ad for the relevant resources (mostly menubar fonts and | |
| 940 fontsets). Do not edit this file, it's purely informative. | |
| 941 | |
| 942 If you have no satisfactory fonts for iso-8859-1, XEmacs will crash. | |
| 943 | |
| 944 It looks like XFree86 4.x (the usual server on Linux and *BSD) has | |
| 945 some braindamage where .UTF-8 locales will always generate this | |
| 946 message, because the XFree86 (font)server doesn't know that UTF-8 will | |
| 947 use the ISO10646-1 font registry (or a Cmap or something). | |
| 948 | |
| 949 If you are not using a .UTF-8 locale and see this warning for a | |
| 950 character set not listed in the default in Emacs.ad, please let | |
| 951 xemacs-beta@xemacs.org know about it, so we can add fonts to the | |
| 952 appropriate fontsets and stifle this warning. (Unfortunately it's | |
| 953 buried in Xlib, so we can't easily get rid of it otherwise.) | |
| 954 | |
| 373 | 955 *** Mail agents (VM, Gnus, rmail) cannot get new mail |
| 197 | 956 |
| 957 rmail and VM get new mail from /usr/spool/mail/$USER using a program | |
| 958 called `movemail'. This program interlocks with /bin/mail using the | |
| 959 protocol defined by /bin/mail. | |
| 960 | |
| 961 There are two different protocols in general use. One of them uses | |
| 962 the `flock' system call. The other involves creating a lock file; | |
| 963 `movemail' must be able to write in /usr/spool/mail in order to do | |
| 964 this. You control which one is used by defining, or not defining, the | |
| 965 macro MAIL_USE_FLOCK in config.h or the m- or s- file it includes. IF | |
| 966 YOU DON'T USE THE FORM OF INTERLOCKING THAT IS NORMAL ON YOUR SYSTEM, | |
| 967 YOU CAN LOSE MAIL! | |
| 968 | |
| 969 If your system uses the lock file protocol, and fascist restrictions | |
| 970 prevent ordinary users from writing the lock files in /usr/spool/mail, | |
| 971 you may need to make `movemail' setgid to a suitable group such as | |
| 972 `mail'. To do this, use the following commands (as root) after doing | |
| 973 the make install. | |
| 974 | |
| 975 chgrp mail movemail | |
| 976 chmod 2755 movemail | |
| 977 | |
| 978 Installation normally copies movemail from the build directory to an | |
| 979 installation directory which is usually under /usr/local/lib. The | |
| 980 installed copy of movemail is usually in the directory | |
| 981 /usr/local/lib/emacs/VERSION/TARGET. You must change the group and | |
| 982 mode of the installed copy; changing the group and mode of the build | |
| 983 directory copy is ineffective. | |
| 984 | |
| 373 | 985 *** Things which should be bold or italic (such as the initial |
| 197 | 986 copyright notice) are not. |
| 0 | 987 |
| 197 | 988 The fonts of the "bold" and "italic" faces are generated from the font |
| 989 of the "default" face; in this way, your bold and italic fonts will | |
| 990 have the appropriate size and family. However, emacs can only be | |
| 991 clever in this way if you have specified the default font using the | |
| 992 XLFD (X Logical Font Description) format, which looks like | |
| 0 | 993 |
| 994 *-courier-medium-r-*-*-*-120-*-*-*-*-*-* | |
| 995 | |
| 197 | 996 if you use any of the other, less strict font name formats, some of |
| 997 which look like: | |
| 998 | |
| 0 | 999 lucidasanstypewriter-12 |
| 1000 and fixed | |
| 1001 and 9x13 | |
| 1002 | |
| 1003 then emacs won't be able to guess the names of the "bold" and "italic" | |
| 1004 versions. All X fonts can be referred to via XLFD-style names, so you | |
| 1005 should use those forms. See the man pages for X(1), xlsfonts(1), and | |
| 1006 xfontsel(1). | |
| 1007 | |
| 373 | 1008 *** The dumped Emacs crashes when run, trying to write pure data. |
| 0 | 1009 |
| 1010 Two causes have been seen for such problems. | |
| 1011 | |
| 1012 1) On a system where getpagesize is not a system call, it is defined | |
| 1013 as a macro. If the definition (in both unexec.c and malloc.c) is wrong, | |
| 1014 it can cause problems like this. You might be able to find the correct | |
| 1015 value in the man page for a.out (5). | |
| 1016 | |
| 1017 2) Some systems allocate variables declared static among the | |
| 1018 initialized variables. Emacs makes all initialized variables in most | |
| 1019 of its files pure after dumping, but the variables declared static and | |
| 1020 not initialized are not supposed to be pure. On these systems you | |
| 1021 may need to add "#define static" to the m- or the s- file. | |
| 1022 | |
| 373 | 1023 *** Reading and writing files is very very slow. |
| 0 | 1024 |
| 1025 Try evaluating the form (setq lock-directory nil) and see if that helps. | |
| 1026 There is a problem with file-locking on some systems (possibly related | |
| 454 | 1027 to NFS) that I don't understand. Please send mail to the address |
| 1332 | 1028 xemacs-beta@xemacs.org if you figure this one out. |
| 0 | 1029 |
| 373 | 1030 *** When emacs starts up, I get lots of warnings about unknown keysyms. |
| 124 | 1031 |
| 1032 If you are running the prebuilt binaries, the Motif library expects to find | |
| 1033 certain thing in the XKeysymDB file. This file is normally in /usr/lib/X11/ | |
| 1034 or in /usr/openwin/lib/. If you keep yours in a different place, set the | |
| 454 | 1035 environment variable $XKEYSYMDB to point to it before starting emacs. If |
| 1036 you still have the problem after doing that, perhaps your version of X is | |
| 2536 | 1037 too old. There is a copy of the MIT X11R6 XKeysymDB file in the emacs `etc' |
| 124 | 1038 directory. Try using that one. |
| 1039 | |
| 3406 | 1040 *** Lots of warnings generated when displaying via ssh X forwarding. |
| 1041 | |
| 1042 If you are seeing a significant number of X11 warnings (in particular | |
| 1043 BadWindow errors) when using XEmacs via ssh X forwarding try using a | |
| 1044 trusted x11 connection instead (for openssh, use -Y instead of -X). | |
| 1045 | |
| 373 | 1046 *** My X resources used to work, and now some of them are being ignored. |
| 0 | 1047 |
| 124 | 1048 Check the resources in .../etc/Emacs.ad (which is the same as the file |
| 1389 | 1049 sample.Xresources). Perhaps some of the default resources built in to |
| 124 | 1050 emacs are now overriding your existing resources. Copy and edit the |
| 1051 resources in Emacs.ad as necessary. | |
| 1052 | |
| 373 | 1053 *** I have focus problems when I use `M-o' to switch to another screen |
| 197 | 1054 without using the mouse. |
| 124 | 1055 |
| 197 | 1056 The focus issues with a program like XEmacs, which has multiple |
| 1057 homogeneous top-level windows, are very complicated, and as a result, | |
| 1058 most window managers don't implement them correctly. | |
| 0 | 1059 |
| 124 | 1060 The R4/R5 version of twm (and all of its descendants) had buggy focus |
| 197 | 1061 handling. Sufficiently recent versions of tvtwm have been fixed. In |
| 1062 addition, if you're using twm, make sure you have not specified | |
| 1063 "NoTitleFocus" in your .tvtwmrc file. The very nature of this option | |
| 1064 makes twm do some illegal focus tricks, even with the patch. | |
| 0 | 1065 |
| 197 | 1066 It is known that olwm and olvwm are buggy, and in different ways. If |
| 1067 you're using click-to-type mode, try using point-to-type, or vice | |
| 1068 versa. | |
| 0 | 1069 |
| 197 | 1070 In older versions of NCDwm, one could not even type at XEmacs windows. |
| 1071 This has been fixed in newer versions (2.4.3, and possibly earlier). | |
| 0 | 1072 |
| 197 | 1073 (Many people suggest that XEmacs should warp the mouse when focusing |
| 1074 on another screen in point-to-type mode. This is not ICCCM-compliant | |
| 1075 behavior. Implementing such policy is the responsibility of the | |
| 1076 window manager itself, it is not legal for a client to do this.) | |
| 0 | 1077 |
| 373 | 1078 *** Emacs spontaneously displays "I-search: " at the bottom of the screen. |
| 0 | 1079 |
| 1080 This means that Control-S/Control-Q (XON/XOFF) "flow control" is being | |
| 1081 used. C-s/C-q flow control is bad for Emacs editors because it takes | |
| 1082 away C-s and C-q as user commands. Since editors do not output long | |
| 1083 streams of text without user commands, there is no need for a | |
| 1084 user-issuable "stop output" command in an editor; therefore, a | |
| 1085 properly designed flow control mechanism would transmit all possible | |
| 1086 input characters without interference. Designing such a mechanism is | |
| 1087 easy, for a person with at least half a brain. | |
| 1088 | |
| 1089 There are three possible reasons why flow control could be taking place: | |
| 1090 | |
| 1091 1) Terminal has not been told to disable flow control | |
| 1092 2) Insufficient padding for the terminal in use | |
| 1093 3) Some sort of terminal concentrator or line switch is responsible | |
| 1094 | |
| 1095 First of all, many terminals have a set-up mode which controls whether | |
| 1096 they generate XON/XOFF flow control characters. This must be set to | |
| 1097 "no XON/XOFF" in order for Emacs to work. Sometimes there is an | |
| 1098 escape sequence that the computer can send to turn flow control off | |
| 1099 and on. If so, perhaps the termcap `ti' string should turn flow | |
| 1100 control off, and the `te' string should turn it on. | |
| 1101 | |
| 1102 Once the terminal has been told "no flow control", you may find it | |
| 1103 needs more padding. The amount of padding Emacs sends is controlled | |
| 1104 by the termcap entry for the terminal in use, and by the output baud | |
| 1105 rate as known by the kernel. The shell command `stty' will print | |
| 1106 your output baud rate; `stty' with suitable arguments will set it if | |
| 1107 it is wrong. Setting to a higher speed causes increased padding. If | |
| 1108 the results are wrong for the correct speed, there is probably a | |
| 1109 problem in the termcap entry. You must speak to a local Unix wizard | |
| 1110 to fix this. Perhaps you are just using the wrong terminal type. | |
| 1111 | |
| 1112 For terminals that lack a "no flow control" mode, sometimes just | |
| 1113 giving lots of padding will prevent actual generation of flow control | |
| 1114 codes. You might as well try it. | |
| 1115 | |
| 1116 If you are really unlucky, your terminal is connected to the computer | |
| 1117 through a concentrator which sends XON/XOFF flow control to the | |
| 1118 computer, or it insists on sending flow control itself no matter how | |
| 1119 much padding you give it. Unless you can figure out how to turn flow | |
| 1120 control off on this concentrator (again, refer to your local wizard), | |
| 1121 you are screwed! You should have the terminal or concentrator | |
| 1122 replaced with a properly designed one. In the mean time, some drastic | |
| 1123 measures can make Emacs semi-work. | |
| 1124 | |
| 1125 You can make Emacs ignore C-s and C-q and let the operating system | |
| 1126 handle them. To do this on a per-session basis, just type M-x | |
| 1127 enable-flow-control RET. You will see a message that C-\ and C-^ are | |
| 1128 now translated to C-s and C-q. (Use the same command M-x | |
| 1129 enable-flow-control to turn *off* this special mode. It toggles flow | |
| 1130 control handling.) | |
| 1131 | |
| 1132 If C-\ and C-^ are inconvenient for you (for example, if one of them | |
| 1133 is the escape character of your terminal concentrator), you can choose | |
| 1134 other characters by setting the variables flow-control-c-s-replacement | |
| 1135 and flow-control-c-q-replacement. But choose carefully, since all | |
| 1136 other control characters are already used by emacs. | |
| 1137 | |
| 1138 IMPORTANT: if you type C-s by accident while flow control is enabled, | |
| 1139 Emacs output will freeze, and you will have to remember to type C-q in | |
| 1140 order to continue. | |
| 1141 | |
| 1142 If you work in an environment where a majority of terminals of a | |
| 1143 certain type are flow control hobbled, you can use the function | |
| 1144 `enable-flow-control-on' to turn on this flow control avoidance scheme | |
| 1145 automatically. Here is an example: | |
| 1146 | |
| 1147 (enable-flow-control-on "vt200" "vt300" "vt101" "vt131") | |
| 1148 | |
| 1149 If this isn't quite correct (e.g. you have a mixture of flow-control hobbled | |
| 1150 and good vt200 terminals), you can still run enable-flow-control | |
| 1151 manually. | |
| 1152 | |
| 1153 I have no intention of ever redesigning the Emacs command set for the | |
| 1154 assumption that terminals use C-s/C-q flow control. XON/XOFF flow | |
| 1155 control technique is a bad design, and terminals that need it are bad | |
| 1156 merchandise and should not be purchased. Now that X is becoming | |
| 1157 widespread, XON/XOFF seems to be on the way out. If you can get some | |
| 1158 use out of GNU Emacs on inferior terminals, more power to you, but I | |
| 1159 will not make Emacs worse for properly designed systems for the sake | |
| 1160 of inferior systems. | |
| 1161 | |
| 373 | 1162 *** Control-S and Control-Q commands are ignored completely. |
| 0 | 1163 |
| 1164 For some reason, your system is using brain-damaged C-s/C-q flow | |
| 1165 control despite Emacs's attempts to turn it off. Perhaps your | |
| 1166 terminal is connected to the computer through a concentrator | |
| 1167 that wants to use flow control. | |
| 1168 | |
| 1169 You should first try to tell the concentrator not to use flow control. | |
| 1170 If you succeed in this, try making the terminal work without | |
| 1171 flow control, as described in the preceding section. | |
| 1172 | |
| 1173 If that line of approach is not successful, map some other characters | |
| 1174 into C-s and C-q using keyboard-translate-table. The example above | |
| 1175 shows how to do this with C-^ and C-\. | |
| 1176 | |
| 373 | 1177 *** Control-S and Control-Q commands are ignored completely on a net |
| 197 | 1178 connection. |
| 0 | 1179 |
| 1180 Some versions of rlogin (and possibly telnet) do not pass flow | |
| 1181 control characters to the remote system to which they connect. | |
| 1182 On such systems, emacs on the remote system cannot disable flow | |
| 1183 control on the local system. | |
| 1184 | |
| 1185 One way to cure this is to disable flow control on the local host | |
| 1186 (the one running rlogin, not the one running rlogind) using the | |
| 1187 stty command, before starting the rlogin process. On many systems, | |
| 120 | 1188 `stty start u stop u' will do this. |
| 0 | 1189 |
| 1190 Some versions of tcsh will prevent even this from working. One way | |
| 1191 around this is to start another shell before starting rlogin, and | |
| 1192 issue the stty command to disable flow control from that shell. | |
| 1193 | |
| 1194 If none of these methods work, the best solution is to type | |
| 120 | 1195 `M-x enable-flow-control' at the beginning of your emacs session, or |
| 0 | 1196 if you expect the problem to continue, add a line such as the |
| 1197 following to your .emacs (on the host running rlogind): | |
| 1198 | |
| 1199 (enable-flow-control-on "vt200" "vt300" "vt101" "vt131") | |
| 1200 | |
| 1201 See the entry about spontaneous display of I-search (above) for more | |
| 1202 info. | |
| 1203 | |
| 373 | 1204 *** TTY redisplay is slow. |
| 197 | 1205 |
| 1206 XEmacs has fairly new TTY redisplay support (beginning from 19.12), | |
| 1207 which doesn't include some basic TTY optimizations -- like using | |
| 1208 scrolling regions to move around blocks of text. This is why | |
| 454 | 1209 redisplay on the traditional terminals, or over slow lines can be very |
| 197 | 1210 slow. |
| 1211 | |
| 1212 If you are interested in fixing this, please let us know at | |
| 1332 | 1213 <xemacs-beta@xemacs.org>. |
| 197 | 1214 |
| 373 | 1215 *** Screen is updated wrong, but only on one kind of terminal. |
| 0 | 1216 |
| 120 | 1217 This could mean that the termcap entry you are using for that terminal |
| 1218 is wrong, or it could mean that Emacs has a bug handing the | |
| 1219 combination of features specified for that terminal. | |
| 0 | 1220 |
| 1221 The first step in tracking this down is to record what characters | |
| 1222 Emacs is sending to the terminal. Execute the Lisp expression | |
| 120 | 1223 (open-termscript "./emacs-script") to make Emacs write all terminal |
| 1224 output into the file ~/emacs-script as well; then do what makes the | |
| 1225 screen update wrong, and look at the file and decode the characters | |
| 1226 using the manual for the terminal. There are several possibilities: | |
| 0 | 1227 |
| 1228 1) The characters sent are correct, according to the terminal manual. | |
| 1229 | |
| 1230 In this case, there is no obvious bug in Emacs, and most likely you | |
| 1231 need more padding, or possibly the terminal manual is wrong. | |
| 1232 | |
| 120 | 1233 2) The characters sent are incorrect, due to an obscure aspect of the |
| 1234 terminal behavior not described in an obvious way by termcap. | |
| 0 | 1235 |
| 120 | 1236 This case is hard. It will be necessary to think of a way for Emacs |
| 1237 to distinguish between terminals with this kind of behavior and other | |
| 1238 terminals that behave subtly differently but are classified the same | |
| 1239 by termcap; or else find an algorithm for Emacs to use that avoids the | |
| 1240 difference. Such changes must be tested on many kinds of terminals. | |
| 0 | 1241 |
| 1242 3) The termcap entry is wrong. | |
| 1243 | |
| 120 | 1244 See the file etc/TERMS for information on changes that are known to be |
| 1245 needed in commonly used termcap entries for certain terminals. | |
| 0 | 1246 |
| 120 | 1247 4) The characters sent are incorrect, and clearly cannot be right for |
| 1248 any terminal with the termcap entry you were using. | |
| 0 | 1249 |
| 120 | 1250 This is unambiguously an Emacs bug, and can probably be fixed in |
| 197 | 1251 termcap.c, terminfo.c, tparam.c, cm.c, redisplay-tty.c, |
| 1252 redisplay-output.c, or redisplay.c. | |
| 0 | 1253 |
| 373 | 1254 *** My buffers are full of \000 characters or otherwise corrupt. |
| 1255 | |
| 1256 Some compilers have trouble with gmalloc.c and ralloc.c; try recompiling | |
| 1257 without optimization. If that doesn't work, try recompiling with | |
| 1258 SYSTEM_MALLOC defined, and/or with REL_ALLOC undefined. | |
| 1259 | |
| 1389 | 1260 *** A position you specified in .Xresources is ignored, using twm. |
| 373 | 1261 |
| 1262 twm normally ignores "program-specified" positions. | |
| 1263 You can tell it to obey them with this command in your `.twmrc' file: | |
| 1264 | |
| 1265 UsePPosition "on" #allow clents to request a position | |
| 1266 | |
| 1267 *** With M-x enable-flow-control, you need to type C-\ twice to do | |
| 1268 incremental search--a single C-\ gets no response. | |
| 1269 | |
| 1270 This has been traced to communicating with your machine via kermit, | |
| 1271 with C-\ as the kermit escape character. One solution is to use | |
| 1272 another escape character in kermit. One user did | |
| 1273 | |
| 1274 set escape-character 17 | |
| 1275 | |
| 1276 in his .kermrc file, to make C-q the kermit escape character. | |
| 1277 | |
| 1278 *** The Motif version of Emacs paints the screen a solid color. | |
| 1279 | |
| 1280 This has been observed to result from the following X resource: | |
| 1281 | |
| 1282 Emacs*default.attributeFont: -*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-* | |
| 1283 | |
| 1284 That the resource has this effect indicates a bug in something, but we | |
| 1285 do not yet know what. If it is an Emacs bug, we hope someone can | |
| 1286 explain what the bug is so we can fix it. In the mean time, removing | |
| 1287 the resource prevents the problem. | |
| 1288 | |
| 1289 *** After running emacs once, subsequent invocations crash. | |
| 1290 | |
| 1291 Some versions of SVR4 have a serious bug in the implementation of the | |
| 1292 mmap () system call in the kernel; this causes emacs to run correctly | |
| 1293 the first time, and then crash when run a second time. | |
| 1294 | |
| 1295 Contact your vendor and ask for the mmap bug fix; in the mean time, | |
| 1296 you may be able to work around the problem by adding a line to your | |
| 1297 operating system description file (whose name is reported by the | |
| 1298 configure script) that reads: | |
| 1299 #define SYSTEM_MALLOC | |
| 1300 This makes Emacs use memory less efficiently, but seems to work around | |
| 1301 the kernel bug. | |
| 1302 | |
| 1303 *** Inability to send an Alt-modified key, when Emacs is communicating | |
| 1304 directly with an X server. | |
| 1305 | |
| 1306 If you have tried to bind an Alt-modified key as a command, and it | |
| 1307 does not work to type the command, the first thing you should check is | |
| 1308 whether the key is getting through to Emacs. To do this, type C-h c | |
| 1309 followed by the Alt-modified key. C-h c should say what kind of event | |
| 1310 it read. If it says it read an Alt-modified key, then make sure you | |
| 1311 have made the key binding correctly. | |
| 1312 | |
| 1313 If C-h c reports an event that doesn't have the Alt modifier, it may | |
| 1314 be because your X server has no key for the Alt modifier. The X | |
| 1315 server that comes from MIT does not set up the Alt modifier by | |
| 1316 default. | |
| 1317 | |
| 1318 If your keyboard has keys named Alt, you can enable them as follows: | |
| 1319 | |
| 1320 xmodmap -e 'add mod2 = Alt_L' | |
| 1321 xmodmap -e 'add mod2 = Alt_R' | |
| 1322 | |
| 1323 If the keyboard has just one key named Alt, then only one of those | |
| 1324 commands is needed. The modifier `mod2' is a reasonable choice if you | |
| 1325 are using an unmodified MIT version of X. Otherwise, choose any | |
| 1326 modifier bit not otherwise used. | |
| 1327 | |
| 1328 If your keyboard does not have keys named Alt, you can use some other | |
| 1329 keys. Use the keysym command in xmodmap to turn a function key (or | |
| 1330 some other 'spare' key) into Alt_L or into Alt_R, and then use the | |
| 1331 commands show above to make them modifier keys. | |
| 1332 | |
| 1333 Note that if you have Alt keys but no Meta keys, Emacs translates Alt | |
| 1334 into Meta. This is because of the great importance of Meta in Emacs. | |
| 1335 | |
| 1336 *** In Shell mode, you get a ^M at the end of every line. | |
| 1337 | |
| 1338 This happens to people who use tcsh, because it is trying to be too | |
| 1339 smart. It sees that the Shell uses terminal type `unknown' and turns | |
| 1340 on the flag to output ^M at the end of each line. You can fix the | |
| 1341 problem by adding this to your .cshrc file: | |
| 1342 | |
| 1343 if ($?EMACS) then | |
| 1344 if ($EMACS == "t") then | |
| 454 | 1345 unset edit |
| 373 | 1346 stty -icrnl -onlcr -echo susp ^Z |
| 1347 endif | |
| 1348 endif | |
| 1349 | |
| 1350 *** An error message such as `X protocol error: BadMatch (invalid | |
| 1351 parameter attributes) on protocol request 93'. | |
| 1352 | |
| 1353 This comes from having an invalid X resource, such as | |
| 1354 emacs*Cursor: black | |
| 1355 (which is invalid because it specifies a color name for something | |
| 1356 that isn't a color.) | |
| 1357 | |
| 1358 The fix is to correct your X resources. | |
| 1359 | |
| 1360 *** Once you pull down a menu from the menubar, it won't go away. | |
| 1361 | |
| 1362 It has been claimed that this is caused by a bug in certain very old | |
| 1363 (1990?) versions of the twm window manager. It doesn't happen with | |
| 1364 recent vintages, or with other window managers. | |
| 1365 | |
| 1366 *** Emacs ignores the "help" key when running OLWM. | |
| 1367 | |
| 1368 OLWM grabs the help key, and retransmits it to the appropriate client | |
| 1369 using XSendEvent. Allowing emacs to react to synthetic events is a | |
| 1370 security hole, so this is turned off by default. You can enable it by | |
| 1371 setting the variable x-allow-sendevents to t. You can also cause fix | |
| 1372 this by telling OLWM to not grab the help key, with the null binding | |
| 1373 "OpenWindows.KeyboardCommand.Help:". | |
| 1374 | |
| 1375 *** Programs running under terminal emulator do not recognize `emacs' | |
| 1376 terminal type. | |
| 1377 | |
| 1378 The cause of this is a shell startup file that sets the TERMCAP | |
| 1379 environment variable. The terminal emulator uses that variable to | |
| 1380 provide the information on the special terminal type that Emacs | |
| 1381 emulates. | |
| 1382 | |
| 1383 Rewrite your shell startup file so that it does not change TERMCAP | |
| 1384 in such a case. You could use the following conditional which sets | |
| 1385 it only if it is undefined. | |
| 1386 | |
| 1387 if ( ! ${?TERMCAP} ) setenv TERMCAP ~/my-termcap-file | |
| 1388 | |
| 1389 Or you could set TERMCAP only when you set TERM--which should not | |
| 1390 happen in a non-login shell. | |
| 1391 | |
| 442 | 1392 *** The popup menu appears at the bottom/right of my screen. |
| 373 | 1393 |
| 1389 | 1394 You probably have something like the following in your ~/.Xresources |
| 373 | 1395 |
| 1396 Emacs.geometry: 81x56--9--1 | |
| 1397 | |
| 1398 Use the following instead | |
| 1399 | |
| 1400 Emacs*EmacsFrame.geometry: 81x56--9--1 | |
| 1401 | |
| 1222 | 1402 *** When I try to use the PostgreSQL functions, I get a message about |
| 1403 undefined symbols. | |
| 1404 | |
| 1405 The only known case in which this happens is if you are using gcc, you | |
|
4842
1d775c6304d1
Use with-FOO consistently instead of enable-FOO
Ben Wing <ben@xemacs.org>
parents:
4753
diff
changeset
|
1406 configured with --with-error-checking=all and --with-modules, and |
| 2648 | 1407 you compiled with no optimization. If you encounter this problem in any |
| 1222 | 1408 other situation, please inform xemacs-beta@xemacs.org. |
| 1409 | |
| 1410 This problem stems from a gcc bug. With no optimization, functions | |
| 1411 declared `extern inline' sometimes are not completely compiled away. An | |
| 1412 undefined symbol with the function's name is put into the resulting | |
| 1413 object file. In this case, when the postgresql module is loaded, the | |
| 1414 linker is unable to resolve that symbol, so the module load fails. The | |
| 1415 workaround is to recompile the module with optimization turned on. Any | |
| 1416 optimization level, including -Os, appears to work. | |
| 1417 | |
| 1332 | 1418 *** C-z just refreshes the screen instead of suspending Emacs. |
| 1419 | |
| 1420 You are probably using a shell that doesn't support job control, even | |
| 1421 though the system itself is capable of it. Try using a different | |
| 1422 shell. | |
| 373 | 1423 |
| 1036 | 1424 ** MacOS/X, Darwin |
|
4753
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1425 *** The linker warns about duplicate symbols. |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1426 |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1427 This occurs in the function alarm(), which we deliberately override, |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1428 and in vendorShellRec when using Xaw3d for the widgets. |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1429 |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1430 For alarm(), the linker chooses our version, as desired. |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1431 Unfortunately, for vendorShellRec, the Xt version is used instead of |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1432 Xaw3d's. This does not seem to cause problems. |
|
dd933a82720c
Describe duplicate symbols warning.
Stephen J. Turnbull <stephen@xemacs.org>
parents:
4634
diff
changeset
|
1433 |
| 1036 | 1434 *** XEmacs crashes on MacOS within font-lock, or when dealing |
| 1435 with large compilation buffers, or in other regex applications. | |
| 1436 | |
| 3074 | 1437 The default stack size under MacOS/X prior to 10.3 (Panther) is rather |
| 1438 small (512k as opposed to Solaris 8M), hosing the regexp code, which | |
| 1439 uses alloca() extensively, overflowing the stack when complex regexps | |
| 1440 are used. Workarounds: | |
| 1036 | 1441 |
| 1442 1) Increase your stack size, using `ulimit -s 8192' or a (t)csh | |
| 1443 equivalent; | |
| 1444 | |
| 1445 2) Recompile regex.c with REGEX_MALLOC defined. | |
| 1446 | |
| 373 | 1447 ** AIX |
| 1448 *** Your Delete key sends a Backspace to the terminal, using an AIXterm. | |
| 0 | 1449 |
| 1389 | 1450 The solution is to include in your .Xresources the lines: |
| 0 | 1451 |
| 1452 *aixterm.Translations: #override <Key>BackSpace: string(0x7f) | |
| 1453 aixterm*ttyModes: erase ^? | |
| 1454 | |
| 1455 This makes your Backspace key send DEL (ASCII 127). | |
| 1456 | |
| 373 | 1457 *** On AIX 4, some programs fail when run in a Shell buffer |
| 1458 with an error message like No terminfo entry for "unknown". | |
| 124 | 1459 |
| 373 | 1460 On AIX, many terminal type definitions are not installed by default. |
| 1461 `unknown' is one of them. Install the "Special Generic Terminal | |
| 1462 Definitions" to make them defined. | |
| 124 | 1463 |
| 373 | 1464 *** On AIX, you get this message when running Emacs: |
| 0 | 1465 |
| 373 | 1466 Could not load program emacs |
| 1467 Symbol smtcheckinit in csh is undefined | |
| 1468 Error was: Exec format error | |
| 124 | 1469 |
| 373 | 1470 or this one: |
| 0 | 1471 |
| 373 | 1472 Could not load program .emacs |
| 1473 Symbol _system_con in csh is undefined | |
| 1474 Symbol _fp_trapsta in csh is undefined | |
| 1475 Error was: Exec format error | |
| 124 | 1476 |
| 373 | 1477 These can happen when you try to run on AIX 3.2.5 a program that was |
| 1478 compiled with 3.2.4. The fix is to recompile. | |
| 124 | 1479 |
| 373 | 1480 *** Trouble using ptys on AIX. |
| 1481 | |
| 1482 People often install the pty devices on AIX incorrectly. | |
| 1483 Use `smit pty' to reinstall them properly. | |
| 1484 | |
| 0 | 1485 |
| 373 | 1486 ** SunOS/Solaris |
| 1487 *** The Emacs window disappears when you type M-q. | |
| 197 | 1488 |
| 373 | 1489 Some versions of the Open Look window manager interpret M-q as a quit |
| 1490 command for whatever window you are typing at. If you want to use | |
| 1491 Emacs with that window manager, you should try to configure the window | |
| 1492 manager to use some other command. You can disable the | |
| 1493 shortcut keys entirely by adding this line to ~/.OWdefaults: | |
| 0 | 1494 |
| 373 | 1495 OpenWindows.WindowMenuAccelerators: False |
| 1496 | |
| 1497 *** When Emacs tries to ring the bell, you get an error like | |
| 124 | 1498 |
| 1499 audio: sst_open: SETQSIZE" Invalid argument | |
| 1500 audio: sst_close: SETREG MMR2, Invalid argument | |
| 1501 | |
| 197 | 1502 you have probably compiled using an ANSI C compiler, but with non-ANSI |
| 1503 include files. In particular, on Suns, the file | |
| 1504 /usr/include/sun/audioio.h uses the _IOW macro to define the constant | |
| 1505 AUDIOSETQSIZE. _IOW in turn uses a K&R preprocessor feature that is | |
| 1506 now explicitly forbidden in ANSI preprocessors, namely substitution | |
| 1507 inside character constants. All ANSI C compilers must provide a | |
| 1508 workaround for this problem. Lucid's C compiler is shipped with a new | |
| 1509 set of system include files. If you are using GCC, there is a script | |
| 1510 called fixincludes that creates new versions of some system include | |
| 1511 files that use this obsolete feature. | |
| 124 | 1512 |
| 373 | 1513 *** On Solaris 2.6, XEmacs dumps core when exiting. |
| 0 | 1514 |
| 373 | 1515 This happens if you're XEmacs is running on the same machine as the X |
| 1516 server, and the optimized memory transport has been turned on by | |
| 1517 setting the environment variable XSUNTRANSPORT. The crash occurs | |
| 1518 during the call to XCloseDisplay. | |
| 124 | 1519 |
| 373 | 1520 If this describes your situation, you need to undefine the |
| 1521 XSUNTRANSPORT environment variable. | |
| 126 | 1522 |
| 373 | 1523 *** On Solaris, C-x doesn't get through to Emacs when you use the console. |
| 124 | 1524 |
| 373 | 1525 This is a Solaris feature (at least on Intel x86 cpus). Type C-r |
| 1526 C-r C-t, to toggle whether C-x gets through to Emacs. | |
| 124 | 1527 |
| 373 | 1528 *** On Solaris 2.4, Dired hangs and C-g does not work. Or Emacs hangs |
| 197 | 1529 forever waiting for termination of a subprocess that is a zombie. |
| 124 | 1530 |
| 1531 casper@fwi.uva.nl says the problem is in X11R6. Rebuild libX11.so | |
| 1532 after changing the file xc/config/cf/sunLib.tmpl. Change the lines | |
| 1533 | |
| 1534 #if ThreadedX | |
| 1535 #define SharedX11Reqs -lthread | |
| 1536 #endif | |
| 1537 | |
| 1538 to: | |
| 1539 | |
| 1540 #if OSMinorVersion < 4 | |
| 1541 #if ThreadedX | |
| 1542 #define SharedX11Reqs -lthread | |
| 1543 #endif | |
| 1544 #endif | |
| 1545 | |
| 1546 Be sure also to edit x/config/cf/sun.cf so that OSMinorVersion is 4 | |
| 1547 (as it should be for Solaris 2.4). The file has three definitions for | |
| 1548 OSMinorVersion: the first is for x86, the second for SPARC under | |
| 1549 Solaris, and the third for SunOS 4. Make sure to update the | |
| 1550 definition for your type of machine and system. | |
| 1551 | |
| 1552 Then do `make Everything' in the top directory of X11R6, to rebuild | |
| 1553 the makefiles and rebuild X. The X built this way work only on | |
| 1554 Solaris 2.4, not on 2.3. | |
| 1555 | |
| 1556 For multithreaded X to work it necessary to install patch | |
| 1557 101925-02 to fix problems in header files [2.4]. You need | |
| 1558 to reinstall gcc or re-run just-fixinc after installing that | |
| 1559 patch. | |
| 0 | 1560 |
| 124 | 1561 However, Frank Rust <frust@iti.cs.tu-bs.de> used a simpler solution: |
| 1562 he changed | |
| 1563 #define ThreadedX YES | |
| 1564 to | |
| 1565 #define ThreadedX NO | |
| 1566 in sun.cf and did `make World' to rebuild X11R6. Removing all | |
| 1567 `-DXTHREAD*' flags and `-lthread' entries from lib/X11/Makefile and | |
| 1568 typing 'make install' in that directory also seemed to work. | |
| 1569 | |
| 373 | 1570 *** On SunOS 4.1.3, Emacs unpredictably crashes in _yp_dobind_soft. |
| 124 | 1571 |
| 373 | 1572 This happens if you configure Emacs specifying just `sparc-sun-sunos4' |
| 1573 on a system that is version 4.1.3. You must specify the precise | |
| 1574 version number (or let configure figure out the configuration, which | |
| 1575 it can do perfectly well for SunOS). | |
| 124 | 1576 |
| 373 | 1577 *** Mail is lost when sent to local aliases. |
| 0 | 1578 |
| 124 | 1579 Many emacs mail user agents (VM and rmail, for instance) use the |
| 1580 sendmail.el library. This library can arrange for mail to be | |
| 1581 delivered by passing messages to the /usr/lib/sendmail (usually) | |
| 1582 program . In doing so, it passes the '-t' flag to sendmail, which | |
| 1583 means that the name of the recipient of the message is not on the | |
| 1584 command line and, therefore, that sendmail must parse the message to | |
| 1585 obtain the destination address. | |
| 1586 | |
| 1587 There is a bug in the SunOS4.1.1 and SunOS4.1.3 versions of sendmail. | |
| 1588 In short, when given the -t flag, the SunOS sendmail won't recognize | |
| 1589 non-local (i.e. NIS) aliases. It has been reported that the Solaris | |
| 1590 2.x versions of sendmail do not have this bug. For those using SunOS | |
| 1591 4.1, the best fix is to install sendmail V8 or IDA sendmail (which | |
| 1592 have other advantages over the regular sendmail as well). At the time | |
| 1593 of this writing, these official versions are available: | |
| 1594 | |
| 1595 Sendmail V8 on ftp.cs.berkeley.edu in /ucb/sendmail: | |
| 1596 sendmail.8.6.9.base.tar.Z (the base system source & documentation) | |
| 1597 sendmail.8.6.9.cf.tar.Z (configuration files) | |
| 1598 sendmail.8.6.9.misc.tar.Z (miscellaneous support programs) | |
| 1599 sendmail.8.6.9.xdoc.tar.Z (extended documentation, with postscript) | |
| 1600 | |
| 1601 IDA sendmail on vixen.cso.uiuc.edu in /pub: | |
| 1602 sendmail-5.67b+IDA-1.5.tar.gz | |
| 1603 | |
| 373 | 1604 *** Emacs fails to understand most Internet host names, even though |
| 124 | 1605 the names work properly with other programs on the same system. |
| 197 | 1606 Emacs won't work with X-windows if the value of DISPLAY is HOSTNAME:0. |
| 1607 Gnus can't make contact with the specified host for nntp. | |
| 0 | 1608 |
| 124 | 1609 This typically happens on Suns and other systems that use shared |
| 1610 libraries. The cause is that the site has installed a version of the | |
| 1611 shared library which uses a name server--but has not installed a | |
| 1612 similar version of the unshared library which Emacs uses. | |
| 0 | 1613 |
| 124 | 1614 The result is that most programs, using the shared library, work with |
| 1615 the nameserver, but Emacs does not. | |
| 1616 | |
| 1617 The fix is to install an unshared library that corresponds to what you | |
| 1618 installed in the shared library, and then relink Emacs. | |
| 0 | 1619 |
| 124 | 1620 On SunOS 4.1, simply define HAVE_RES_INIT. |
| 1621 | |
| 1622 If you have already installed the name resolver in the file libresolv.a, | |
| 1623 then you need to compile Emacs to use that library. The easiest way to | |
| 1624 do this is to add to config.h a definition of LIBS_SYSTEM, LIBS_MACHINE | |
| 1625 or LIB_STANDARD which uses -lresolv. Watch out! If you redefine a macro | |
| 1626 that is already in use in your configuration to supply some other libraries, | |
| 1627 be careful not to lose the others. | |
| 1628 | |
| 1629 Thus, you could start by adding this to config.h: | |
| 1630 | |
| 1631 #define LIBS_SYSTEM -lresolv | |
| 1632 | |
| 1633 Then if this gives you an error for redefining a macro, and you see that | |
| 1634 the s- file defines LIBS_SYSTEM as -lfoo -lbar, you could change config.h | |
| 1635 again to say this: | |
| 1636 | |
| 1637 #define LIBS_SYSTEM -lresolv -lfoo -lbar | |
| 1638 | |
| 373 | 1639 *** With process-connection-type set to t, each line of subprocess |
| 1640 output is terminated with a ^M, making ange-ftp and GNUS not work. | |
| 1641 | |
| 1642 On SunOS systems, this problem has been seen to be a result of an | |
| 1643 incomplete installation of gcc 2.2 which allowed some non-ANSI | |
| 1644 compatible include files into the compilation. In particular this | |
| 1645 affected virtually all ioctl() calls. | |
| 1646 | |
| 1647 | |
| 1648 ** Linux | |
| 845 | 1649 *** XEmacs crashes on startup, in make-frame. |
| 1650 | |
| 1651 Typically the Lisp backtrace includes | |
| 1652 | |
| 1653 make-frame(nil #<x-device on ":0.0" 0x2558>) | |
| 1654 | |
| 2648 | 1655 somewhere near the top. The problem is due to an improvement in GNU ld |
| 1656 that sorts the ELF reloc sections in the executable, giving dramatic | |
| 1657 speedups in startup for large executables. It also confuses the | |
| 1658 traditional unexec code in XEmacs, leading to the core dump. The | |
|
4842
1d775c6304d1
Use with-FOO consistently instead of enable-FOO
Ben Wing <ben@xemacs.org>
parents:
4753
diff
changeset
|
1659 solution is to use the --with-pdump or --with-ldflags='-z nocombreloc' |
| 2648 | 1660 options to configure. Recent 21.4 and 12.5 autodetect this in |
| 1661 configure. | |
| 845 | 1662 |
| 1663 Red Hat and SuSE (at least) distributed a prerelease version of ld | |
| 1664 (versions around 2.11.90.x.y) where autodetection is impossible. The | |
| 1665 recommended procedure is to upgrade to binutils >= 2.12 and rerun | |
|
4842
1d775c6304d1
Use with-FOO consistently instead of enable-FOO
Ben Wing <ben@xemacs.org>
parents:
4753
diff
changeset
|
1666 configure. Otherwise you must apply the flags by hand. --with-pdump |
| 2648 | 1667 is recommended. |
| 448 | 1668 |
| 1669 *** I want XEmacs to use the Alt key, not the XXX key, for Meta commands | |
| 1670 | |
| 1671 For historical reasons, XEmacs looks for a Meta key, then an Alt key. | |
| 1672 It binds Meta commands to the X11 modifier bit attached to the first | |
| 1673 of these it finds. On PCs, the Windows key is often assigned the Meta | |
| 1674 bit, but many desktop environments go to great lengths to get all apps | |
| 1675 to use the Alt key, and reserve the Windows key to (sensibly enough) | |
| 1676 the window manager. | |
| 1677 | |
| 1678 One correct way to implement this was suggested on comp.emacs.xemacs | |
| 1679 (by Kilian Foth and in more detail by Michael Piotrowski): unmap the | |
| 1680 Meta modifier using xmodmap or xkb, and then map the Meta/Windows key | |
| 450 | 1681 to the Super or Hyper keysym and an appropriate mod bit. XEmacs will |
| 1682 not find the Meta keysym, and default to using the Alt key for Meta | |
| 1683 keybindings. Typically few applications use the (X11) Meta modifier; | |
| 1684 it is tedious but not too much so to teach the ones you need to use | |
| 1685 Super instead of Meta. There may be further useful hints in the | |
| 1686 discussion of keymapping on non-Linux platforms. | |
| 1687 | |
| 1688 *** The color-gcc wrapper | |
| 1689 | |
| 1690 This wrapper colorizes the error messages from gcc. By default XEmacs | |
| 1691 does not interpret the escape sequences used to generate colors, | |
| 1692 resulting in a cluttered, hard-to-read buffer. You can remove the | |
| 1693 wrapper, or defeat the wrapper colorization in Emacs process buffers | |
| 1694 by editing the "nocolor" attribute in /etc/colorgccrc: | |
| 1695 | |
| 1696 $ diff -u /etc/colorgccrc.old /etc/colorgccrc | |
| 1697 --- /etc/colorgccrc.old Tue Dec 26 02:17:46 2000 | |
| 1698 +++ /etc/colorgccrc Tue Dec 26 02:15:48 2000 | |
| 1699 @@ -34,1 +34,1 @@ | |
| 1700 -nocolor: dumb | |
| 1701 +nocolor: dumb emacs | |
| 1702 | |
| 1703 If you want colorization in your Emacs buffers, you may get good | |
| 1704 results from the ansi-color.el library: | |
| 1705 | |
| 1706 http://www.geocities.com/kensanata/color-emacs.html#ansicolors | |
| 1707 | |
| 1708 This is written for the mainline GNU Emacs but the author has made | |
| 1709 efforts to adapt it to XEmacs. YMMV. | |
| 448 | 1710 |
| 373 | 1711 *** Slow startup on Linux. |
| 1712 | |
| 1713 People using systems based on the Linux kernel sometimes report that | |
| 448 | 1714 startup takes 10 to 15 seconds longer than `usual'. There are two |
| 1715 problems, one older, one newer. | |
| 1716 | |
| 1717 **** Old problem: IPv4 host lookup | |
| 373 | 1718 |
| 448 | 1719 On older systems, this is because Emacs looks up the host name when it |
| 1720 starts. Normally, this takes negligible time; the extra delay is due | |
| 1721 to improper system configuration. (Recent Linux distros usually have | |
| 1722 this configuration correct "out of the box".) This problem can occur | |
| 1723 for both networked and non-networked machines. | |
| 373 | 1724 |
| 1725 Here is how to fix the configuration. It requires being root. | |
| 1726 | |
| 448 | 1727 ***** Networked Case |
| 373 | 1728 |
| 1729 First, make sure the files `/etc/hosts' and `/etc/host.conf' both | |
| 1730 exist. The first line in the `/etc/hosts' file should look like this | |
| 1731 (replace HOSTNAME with your host name): | |
| 1732 | |
| 1733 127.0.0.1 localhost HOSTNAME | |
| 1734 | |
| 1735 Also make sure that the `/etc/host.conf' files contains the following | |
| 1736 lines: | |
| 1737 | |
| 454 | 1738 order hosts, bind |
| 373 | 1739 multi on |
| 1740 | |
| 1741 Any changes, permanent and temporary, to the host name should be | |
| 1742 indicated in the `/etc/hosts' file, since it acts a limited local | |
| 1743 database of addresses and names (e.g., some SLIP connections | |
| 1744 dynamically allocate ip addresses). | |
| 1745 | |
| 448 | 1746 ***** Non-Networked Case |
| 373 | 1747 |
| 1748 The solution described in the networked case applies here as well. | |
| 1749 However, if you never intend to network your machine, you can use a | |
| 1750 simpler solution: create an empty `/etc/host.conf' file. The command | |
| 1751 `touch /etc/host.conf' suffices to create the file. The `/etc/hosts' | |
| 1752 file is not necessary with this approach. | |
| 1753 | |
| 448 | 1754 **** New problem: IPv6 CNAME lookup |
| 1755 | |
| 1756 A newer problem is due to XEmacs changing to use the modern | |
| 1757 getaddrinfo() interface from the older gethostbyname() interface. The | |
| 1758 solution above is insufficient, because getaddrinfo() by default tries | |
| 1759 to get IPv6 information for localhost. This always involves a dns | |
| 1760 lookup to get the CNAME, and the strategies above don't work. It then | |
| 724 | 1761 falls back to IPv4 behavior. This is good[tm] according the people at |
| 1762 WIDE who know about IPv6. | |
| 448 | 1763 |
| 1764 ***** Robust network case | |
| 1765 | |
| 1766 Configure your network so that there are no nameservers configured | |
| 1767 until the network is actually running. getaddrinfo() will not try to | |
| 1768 access a nameserver that isn't configured. | |
| 1769 | |
| 1770 ***** Flaky network case | |
| 1771 | |
| 1772 If you have a flaky modem or DSL connection that can be relied on only | |
| 1773 to go down whenever you want to bring XEmacs up, you need to force | |
| 1774 IPv4 behavior. Explicitly setting DISPLAY=127.0.0.1:0.0 (or whatever | |
| 1775 is appropriate) works in most cases. | |
| 1776 | |
| 1777 If you cannot or do not want to do that, you can hard code IPv4 | |
| 1778 behavior in src/process-unix.c. This is bad[tm], on your own head be | |
| 724 | 1779 it. Use the configure option `--with-ipv6-cname=no'. |
| 373 | 1780 |
| 845 | 1781 *** Mandrake |
| 1782 | |
| 1783 The Mandrake Linux distribution is attempting to comprehensively | |
| 1784 update the user interface, and make it consistent across | |
| 1785 applications. This is very difficult, and will occasionally cause | |
| 1786 conflicts with applications like Emacs with their own long-established | |
| 1787 interfaces. Known issues specific to Mandrake or especially common: | |
| 1788 | |
| 1789 Some versions of XEmacs (21.1.9 is known) distributed with Mandrake | |
| 1790 were patched to make the Meta and Alt keysyms synonymous. These | |
| 1791 normally work as expected in the Mandrake environment. However, | |
| 1792 custom-built XEmacsen (including all 21.2 betas) will "inexplicably" | |
| 1793 not respect the "Alt-invokes-Meta-commands" convention. See "I want | |
| 1794 XEmacs to use the Alt key" below. | |
| 1795 | |
| 1796 The color-gcc wrapper (see below) is in common use on the Mandrake | |
| 1797 platform. | |
| 1798 | |
| 1799 *** You get crashes in a non-C locale with Linux GNU Libc 2.0. | |
| 1800 | |
| 1801 Internationalization was not the top priority for GNU Libc 2.0. | |
| 1802 As of this writing (1998-12-28) you may get crashes while running | |
| 1803 XEmacs in a non-C locale. For example, `LC_ALL=en_US xemacs' crashes | |
| 1804 while `LC_ALL=C xemacs' runs fine. This happens for example with GNU | |
| 1805 libc 2.0.7. Installing libintl.a and libintl.h built from gettext | |
| 1806 0.10.35 and re-building XEmacs solves the crashes. Presumably soon | |
| 1807 everyone will upgrade to GNU Libc 2.1 and this problem will go away. | |
| 1808 | |
| 1809 *** `C-z', or `M-x suspend-emacs' hangs instead of suspending. | |
| 1810 | |
| 1811 If you build with `gpm' support on Linux, you cannot suspend XEmacs | |
| 1812 because gpm installs a buggy SIGTSTP handler. Either compile with | |
| 1813 `--with-gpm=no', or don't suspend XEmacs on the Linux console until | |
| 1814 this bug is fixed. | |
| 1815 | |
| 1816 *** With certain fonts, when the cursor appears on a character, the | |
| 1817 character doesn't appear--you get a solid box instead. | |
| 1818 | |
| 1819 One user on a Linux system reported that this problem went away with | |
| 1820 installation of a new X server. The failing server was XFree86 3.1.1. | |
| 1821 XFree86 3.1.2 works. | |
| 1822 | |
| 373 | 1823 ** IRIX |
| 1824 *** On Irix, I don't see the toolbar icons and I'm getting lots of | |
| 1825 entries in the warnings buffer. | |
| 1826 | |
| 1827 SGI ships a really old Xpm library in /usr/lib which does not work at | |
| 1828 all well with XEmacs. The solution is to install your own copy of the | |
| 2648 | 1829 latest version of Xpm somewhere and then use the --with-site-includes |
| 1830 and --with-site-libraries flags to tell configure where to find it. | |
| 373 | 1831 |
| 1832 *** Trouble using ptys on IRIX, or running out of ptys. | |
| 1833 | |
| 1834 The program mkpts (which may be in `/usr/adm' or `/usr/sbin') needs to | |
| 1835 be set-UID to root, or non-root programs like Emacs will not be able | |
| 1836 to allocate ptys reliably. | |
| 1837 | |
| 1838 *** Beware of the default image & graphics library on Irix | |
| 1839 | |
| 1840 Richard Cognot <cognot@ensg.u-nancy.fr> writes: | |
| 1841 | |
| 1842 You *have* to compile your own jpeg lib. The one delivered with SGI | |
| 1843 systems is a C++ lib, which apparently XEmacs cannot cope with. | |
| 1844 | |
| 1845 | |
| 1846 ** Digital UNIX/OSF/VMS/Ultrix | |
| 1847 *** XEmacs crashes on Digital Unix within font-lock, or when dealing | |
| 1036 | 1848 with large compilation buffers, or in other regex applications. |
| 373 | 1849 |
| 1850 The default stack size under Digital Unix is rather small (2M as | |
| 1851 opposed to Solaris 8M), hosing the regexp code, which uses alloca() | |
| 1852 extensively, overflowing the stack when complex regexps are used. | |
| 1853 Workarounds: | |
| 312 | 1854 |
| 373 | 1855 1) Increase your stack size, using `ulimit -s 8192' or a (t)csh |
| 1856 equivalent; | |
| 1857 | |
| 1858 2) Recompile regex.c with REGEX_MALLOC defined. | |
| 1859 | |
| 1860 *** The `Alt' key doesn't behave as `Meta' when running DECwindows. | |
| 1861 | |
| 1862 The default DEC keyboard mapping has the Alt keys set up to generate the | |
| 1863 keysym `Multi_key', which has a meaning to xemacs which is distinct from that | |
| 1864 of the `Meta_L' and `Meta-R' keysyms. A second problem is that certain keys | |
| 1865 have the Mod2 modifier attached to them for no adequately explored reason. | |
| 1866 The correct fix is to pass this file to xmodmap upon starting X: | |
| 1867 | |
| 1868 clear mod2 | |
| 1869 keysym Multi_key = Alt_L | |
| 1870 add mod1 = Alt_L | |
| 1871 add mod1 = Alt_R | |
| 1872 | |
| 1873 *** The Compose key on a DEC keyboard does not work as Meta key. | |
| 1874 | |
| 1875 This shell command should fix it: | |
| 1876 | |
| 1877 xmodmap -e 'keycode 0xb1 = Meta_L' | |
| 1878 | |
| 1879 *** `expand-file-name' fails to work on any but the machine you dumped | |
| 1880 Emacs on. | |
| 1881 | |
| 1882 On Ultrix, if you use any of the functions which look up information | |
| 1883 in the passwd database before dumping Emacs (say, by using | |
| 1884 expand-file-name in site-init.el), then those functions will not work | |
| 1885 in the dumped Emacs on any host but the one Emacs was dumped on. | |
| 1886 | |
| 1887 The solution? Don't use expand-file-name in site-init.el, or in | |
| 1888 anything it loads. Yuck - some solution. | |
| 1889 | |
| 1890 I'm not sure why this happens; if you can find out exactly what is | |
| 1891 going on, and perhaps find a fix or a workaround, please let us know. | |
| 1892 Perhaps the YP functions cache some information, the cache is included | |
| 1893 in the dumped Emacs, and is then inaccurate on any other host. | |
| 1894 | |
| 1895 | |
| 1896 ** HP-UX | |
| 1897 *** I get complaints about the mapping of my HP keyboard at startup, | |
| 1898 but I haven't changed anything. | |
| 1899 | |
| 1900 The default HP keymap is set up to have Mod1 assigned to two different keys: | |
| 1901 Meta_L and Mode_switch (even though there is not actually a Mode_switch key on | |
| 1902 the keyboard -- it uses an "imaginary" keycode.) There actually is a reason | |
| 1903 for this, but it's not a good one. The correct fix is to execute this command | |
| 1904 upon starting X: | |
| 1905 | |
| 1906 xmodmap -e 'remove mod1 = Mode_switch' | |
| 312 | 1907 |
| 373 | 1908 *** On HP-UX, you get "poll: Interrupted system call" message in the |
| 1909 window where XEmacs was launched. | |
| 1910 | |
| 1911 Richard Cognot <cognot@ensg.u-nancy.fr> writes: | |
| 1912 | |
| 1913 I get a very strange problem when linking libc.a dynamically: every | |
| 1914 event (mouse, keyboard, expose...) results in a "poll: Interrupted | |
| 1915 system call" message in the window where XEmacs was | |
| 1916 launched. Forcing a static link of libc.a alone by adding | |
| 1917 /usr/lib/libc.a at the end of the link line solves this. Note that | |
| 1918 my 9.07 build of 19.14b17 and my (old) build of 19.13 both exhibit | |
| 442 | 1919 the same behavior. I've tried various hpux patches to no avail. If |
| 373 | 1920 this problem cannot be solved before the release date, binary kits |
| 1921 for HP *must* be linked statically against libc, otherwise this | |
| 1922 problem will show up. (This is directed at whoever will volunteer | |
| 1923 for this kit, as I won't be available to do it, unless 19.14 gets | |
| 1924 delayed until mid-june ;-). I think this problem will be an FAQ soon | |
| 1925 after the release otherwise. | |
| 1926 | |
| 1927 Note: The above entry is probably not valid for XEmacs 21.0 and | |
| 1928 later. | |
| 1929 | |
| 1930 *** The right Alt key works wrong on German HP keyboards (and perhaps | |
| 1931 other non-English HP keyboards too). | |
| 1932 | |
| 1933 This is because HP-UX defines the modifiers wrong in X. Here is a | |
| 1934 shell script to fix the problem; be sure that it is run after VUE | |
| 1935 configures the X server. | |
| 1936 | |
| 1937 xmodmap 2> /dev/null - << EOF | |
| 1938 keysym Alt_L = Meta_L | |
| 1939 keysym Alt_R = Meta_R | |
| 1940 EOF | |
| 1941 | |
| 1942 xmodmap - << EOF | |
| 1943 clear mod1 | |
| 1944 keysym Mode_switch = NoSymbol | |
| 1945 add mod1 = Meta_L | |
| 1946 keysym Meta_R = Mode_switch | |
| 1947 add mod2 = Mode_switch | |
| 1948 EOF | |
| 1949 | |
| 442 | 1950 |
| 1951 *** XEmacs dumps core at startup when native audio is used. Native | |
| 1952 audio does not work with recent versions of HP-UX. | |
| 1953 | |
| 1954 Under HP-UX 10.20 and later (e.g., HP-UX 11.XX), with native audio | |
| 1955 enabled, the dumped XEmacs binary ("xemacs") core dumps at startup if | |
| 1956 recent versions of the libAlib.sl audio shared library is used. Note | |
| 1957 that "temacs" will run, but "xemacs" will dump core. This, of course, | |
| 1958 causes the XEmacs build to fail. If GNU malloc is enabled, a stack | |
| 1959 trace will show XEmacs to have crashed in the "first" call to malloc(). | |
| 1960 | |
| 1961 This bug currently exists in all versions of XEmacs, when the undump | |
| 1962 mechanism is used. It is not known if using the experimental portable | |
| 1963 dumper will allow native audio to work. | |
| 1964 | |
| 1965 **** Cause: | |
| 1966 | |
| 1967 Recent versions of the HP-UX 10.20 (and later) audio shared library (in | |
| 1968 /opt/audio/lib), pulls in the libdce shared library, which pulls in a | |
| 1969 thread (libcma) library. This prevents the HP-UX undump() routine (in | |
| 1970 unexhp9k800.c) from properly working. What's happening is that some | |
| 1971 initialization routines are being called in the libcma library, *BEFORE* | |
| 1972 main() is called, and these initialization routines are calling | |
| 1973 malloc(). Unfortunately, in order for the undumper to work, XEmacs must | |
| 1974 adjust (move upwards) the sbrk() value *BEFORE* the first call to | |
| 1975 malloc(); if malloc() is called before XEmacs has properly adjusted sbrk | |
| 1976 (which is what is happening), dumped memory that is being used by | |
| 1977 XEmacs, is improperly re-allocated for use by malloc() and the dumped | |
| 1978 memory is corrupted. This causes XEmacs to die an horrible death. | |
| 1979 | |
| 1980 It is believed that versions of the audio library past December 1998 | |
| 1981 will trigger this problem. Under HP-UX 10.20, you probably have to | |
| 1982 install audio library patches to encounter this. It's probable that | |
| 1983 recent "fresh, out-of-the-box" HP-UX 11.XX workstations also have this | |
| 1984 problem. For HP-UX 10.20, it's believed that audio patch PHSS_17121 (or | |
| 1985 a superceeding one, like PHSS_17554, PHSS_17971, PHSS_18777, PHSS_21481, | |
| 1986 or PHSS_21662, etc.) will trigger this. | |
| 1987 | |
| 1988 To check if your audio library will cause problems for XEmacs, run | |
| 1989 "chatr /opt/audio/lib/libAlib.sl". If "libdce" appears in the displayed | |
| 1990 shared library list, XEmacs will probably encounter problems if audio is | |
| 1991 enabled. | |
| 1992 | |
| 1993 **** Workaround: | |
| 1994 | |
| 1995 Don't enable native audio. Re-run configure without native audio | |
| 1996 support. | |
| 1997 | |
| 1998 If your site supports it, try using NAS (Network Audio Support). | |
| 1999 | |
| 2000 Try using the experimental portable dumper. It may work, or it may | |
| 2001 not. | |
| 2002 | |
| 2003 | |
| 373 | 2004 *** `Pid xxx killed due to text modification or page I/O error' |
| 2005 | |
| 2006 On HP-UX, you can get that error when the Emacs executable is on an NFS | |
| 2007 file system. HP-UX responds this way if it tries to swap in a page and | |
| 2008 does not get a response from the server within a timeout whose default | |
| 2009 value is just ten seconds. | |
| 2010 | |
| 2011 If this happens to you, extend the timeout period. | |
| 2012 | |
| 2013 *** Shell mode on HP-UX gives the message, "`tty`: Ambiguous". | |
| 124 | 2014 |
| 2015 christos@theory.tn.cornell.edu says: | |
| 2016 | |
| 2017 The problem is that in your .cshrc you have something that tries to | |
| 197 | 2018 execute `tty`. If you are not running the shell on a real tty then tty |
| 2019 will print "not a tty". Csh expects one word in some places, but tty | |
| 2020 is giving it back 3. | |
| 124 | 2021 |
| 197 | 2022 The solution is to add a pair of quotes around `tty` to make it a |
| 2023 single word: | |
| 0 | 2024 |
| 454 | 2025 if (`tty` == "/dev/console") |
| 124 | 2026 |
| 2027 should be changed to: | |
| 2028 | |
| 454 | 2029 if ("`tty`" == "/dev/console") |
| 124 | 2030 |
| 2031 Even better, move things that set up terminal sections out of .cshrc | |
| 2032 and into .login. | |
| 0 | 2033 |
| 2034 | |
| 373 | 2035 ** SCO |
| 2036 *** Regular expressions matching bugs on SCO systems. | |
| 0 | 2037 |
| 373 | 2038 On SCO, there are problems in regexp matching when Emacs is compiled |
| 2039 with the system compiler. The compiler version is "Microsoft C | |
| 2040 version 6", SCO 4.2.0h Dev Sys Maintenance Supplement 01/06/93; Quick | |
| 2041 C Compiler Version 1.00.46 (Beta). The solution is to compile with | |
| 2042 GCC. | |
| 124 | 2043 |
| 88 | 2044 |
| 373 | 2045 ** Windows |
| 1332 | 2046 *** Conflicts with FSF NTEmacs |
| 2047 | |
| 2048 Depending on how it is installed, FSF NTEmacs may setup various EMACS* | |
| 2049 variables in your environment. The presence of these variables may | |
| 2050 cause XEmacs to fail at startup, cause you to see corrupted | |
| 2051 doc-strings, or cause other random problems. | |
| 2052 | |
| 2053 You should remove these variables from your environment. These | |
| 2054 variables are not required to run FSF NTEmacs if you start it by | |
| 2055 running emacs.bat. | |
| 2056 | |
| 2057 *** XEmacs can't find my init file | |
| 2058 | |
| 2059 XEmacs looks for your init in your "home" directory -- either in | |
| 2060 `~/.xemacs/init.el' or `~/.emacs'. XEmacs decides that your "home" | |
| 2061 directory is, in order of preference: | |
| 2062 | |
| 2063 - The value of the HOME environment variable, if the variable exists. | |
| 2064 - The value of the registry entry SOFTWARE\XEmacs\XEmacs\HOME, | |
| 2065 if it exists. | |
| 2066 - The value of the HOMEDRIVE and HOMEPATH environment variables, if | |
| 2067 these variables both exist. | |
| 2068 - C:\. | |
| 2069 | |
| 2070 To determine what XEmacs thinks your home directory is, try opening | |
| 2071 a file in the `~' directory, and you should see its expansion in the | |
| 2072 modeline. If this doesn't work, type ESC : (user-home-directory). | |
| 2073 | |
| 2074 *** XEmacs can't find any packages | |
| 2075 | |
| 2076 XEmacs looks for your packages in subdirectories of a directory which | |
| 2077 is set at compile-time (see `config.inc'), and whose default is | |
| 2078 `C:\Program Files\XEmacs'. XEmacs also looks in `~/.xemacs', where | |
| 2079 `~' refers to your home directory (see previous entry). The variable | |
| 2080 `configure-package-path' holds the actual path that was compiled into | |
| 2081 your copy of XEmacs. | |
| 2082 | |
| 2083 The compile-time default location can be overridden by the EMACSPACKAGEPATH | |
| 2084 environment variable or by the SOFTWARE\XEmacs\XEmacs\EMACSPACKAGEPATH | |
| 2085 registry entry. You should check that these variables, if they exist, | |
| 2086 point to the actual location of your package tree. | |
| 2087 | |
| 2088 *** XEmacs doesn't die when shutting down Windows 95 or 98 | |
| 2089 | |
| 2090 When shutting down Windows 95 or 98 you may see a dialog that says | |
| 2091 "xemacs / You must quit this program before you quit Windows". | |
| 2092 It is safe to | |
| 2093 "Click OK to quit the program and Windows", | |
| 2094 but you won't be offered a chance to save any modified XEmacs buffers. | |
| 2095 | |
| 2096 *** Key bindings | |
| 2097 | |
| 2098 The C-z, C-x, C-c, and C-v keystrokes have traditional uses in both | |
| 2099 emacs and Windows programs. XEmacs binds these keys to their | |
| 2100 traditional emacs uses, and provides Windows 3.x style bindings for | |
| 2101 the Cut, Copy and Paste functions. | |
| 2102 | |
| 2103 Function XEmacs binding | |
| 2104 -------- -------------- | |
| 2105 Undo C-_ | |
| 2106 Cut Sh-Del | |
| 2107 Copy C-Insert | |
| 2108 Paste Sh-Insert | |
| 2109 | |
| 2110 You can rebind keys to make XEmacs more Windows-compatible; for | |
| 2111 example, to bind C-z to undo: | |
| 2112 | |
| 2113 (global-set-key [(control z)] 'undo) | |
| 2114 | |
| 2115 Rebindind C-x and C-c is trickier because by default these are prefix | |
| 2116 keys in XEmacs. See the "Key Bindings" node in the XEmacs manual. | |
| 2117 | |
| 2118 *** Behavior of selected regions | |
| 2119 | |
| 2120 Use the pending-del package to enable the standard Windows behavior of | |
| 2121 self-inserting deletes region. | |
| 2122 | |
| 2123 *** Limitations on the use of the AltGr key. | |
| 2124 | |
| 2125 In some locale and OS combinations you can't generate M-AltGr-key or | |
| 2126 C-M-AltGr-key sequences at all. | |
| 2127 | |
| 2128 To generate C-AltGr-key or C-M-AltGr-key sequences you must use the | |
| 2129 right-hand Control key and you must press it *after* AltGr. | |
| 2130 | |
| 2131 These limitations arise from fundamental problems in the way that the | |
| 2132 win32 API reports AltGr key events. There isn't anything that XEmacs | |
| 2133 can do to work round these problems that it isn't already doing. | |
| 2134 | |
| 2135 You may want to create alternative bindings if any of the standard | |
| 2136 XEmacs bindings require you to use some combination of Control or Meta | |
| 2137 and AltGr. | |
| 2138 | |
| 2139 *** Limited support for subprocesses under Windows 9x | |
| 2140 | |
| 2141 Attempting to use call-process to run a 16bit program gives a | |
| 2142 "Spawning child process: Exec format error". For example shell-command | |
| 2143 fails under Windows 95 and 98 if you use command.com or any other | |
| 2144 16bit program as your shell. | |
| 2145 | |
| 2146 XEmacs may incorrectly quote your call-process command if it contains | |
| 2147 double quotes, backslashes or spaces. | |
| 2148 | |
| 2149 start-process and functions that rely on it are supported under Windows 95, | |
| 2150 98 and NT. However, starting a 16bit program that requires keyboard input | |
| 2151 may cause XEmacs to hang or crash under Windows 95 and 98, and will leave | |
| 2152 the orphaned 16bit program consuming all available CPU time. | |
| 2153 | |
| 2154 Sending signals to subprocesses started by call-process or by | |
| 2155 start-process fails with a "Cannot send signal to process" error under | |
| 2156 Windows 95 and 98. As a side effect of this, quitting XEmacs while it | |
| 2157 is still running subprocesses causes it to crash under Windows 95 and | |
| 2158 98. | |
| 524 | 2159 |
| 2160 | |
| 2161 ** Cygwin | |
| 1318 | 2162 *** Signal 11 when building or running a dumped XEmacs. |
| 2163 | |
| 2164 See the section on Cygwin above, under building. | |
| 2165 | |
| 1058 | 2166 *** XEmacs fails to start because cygXpm-noX4.dll was not found. |
| 2167 | |
| 2168 Andy Piper <andy@xemacs.org> sez: | |
| 2169 | |
| 2170 cygXpm-noX4 is part of the cygwin distribution under libraries or | |
| 2171 graphics, but is not installed by default. You need to run the | |
| 2172 cygwin setup again and select this package. | |
| 2173 | |
| 524 | 2174 *** Subprocesses do not work. |
| 2175 | |
| 2176 You do not have "tty" in your CYGWIN environment variable. This must | |
| 2177 be set in your autoexec.bat (win95) or the system properties (winnt) | |
| 2178 as it must be read before the cygwin DLL initializes. | |
| 2179 | |
| 2180 *** ^G does not work on hung subprocesses. | |
| 124 | 2181 |
| 524 | 2182 This is a known problem. It can be remedied by defining BROKEN_SIGIO |
| 2183 in src/s/cygwin.h, however this currently leads to instability in XEmacs. | |
| 2184 (#### is this still true?) | |
| 2185 | |
| 2186 *** Errors from make like `/c:not found' when running `M-x compile'. | |
| 308 | 2187 |
| 524 | 2188 Make sure you set the environment variable MAKE_MODE to UNIX in your |
| 2189 init file (.xemacs/init.el), Control Panel (Windows 2000/NT), or | |
| 2190 AUTOEXEC.BAT (Windows 98/95). | |
| 2191 | |
| 2192 *** There are no images in the toolbar buttons. | |
| 2193 | |
| 2194 You need version 4.71 of commctrl.dll which does not ship with windows | |
| 2195 95. You can get this by installing IE 4.0 or downloading it from the | |
| 2196 microsoft website. | |
| 308 | 2197 |
| 197 | 2198 |
| 124 | 2199 * Compatibility problems (with Emacs 18, GNU Emacs, or previous XEmacs/lemacs) |
| 197 | 2200 ============================================================================== |
| 88 | 2201 |
| 373 | 2202 *** "Symbol's value as variable is void: unread-command-char". |
| 197 | 2203 "Wrong type argument: arrayp, #<keymap 143 entries>" |
| 2204 "Wrong type argument: stringp, [#<keypress-event return>]" | |
| 88 | 2205 |
| 124 | 2206 There are a few incompatible changes in XEmacs, and these are the |
| 2207 symptoms. Some of the emacs-lisp code you are running needs to be | |
| 2208 updated to be compatible with XEmacs. | |
| 2209 | |
| 2210 The code should not treat keymaps as arrays (use `define-key', etc.), | |
| 2211 should not use obsolete variables like `unread-command-char' (use | |
| 197 | 2212 `unread-command-events'). Many (most) of the new ways of doing things |
| 124 | 2213 are compatible in GNU Emacs and XEmacs. |
| 88 | 2214 |
| 197 | 2215 Modern Emacs packages (Gnus, VM, W3, efs, etc) are written to support |
| 2216 GNU Emacs and XEmacs. We have provided modified versions of several | |
| 2217 popular emacs packages (dired, etc) which are compatible with this | |
| 2218 version of emacs. Check to make sure you have not set your load-path | |
| 2219 so that your private copies of these packages are being found before | |
| 2220 the versions in the lisp directory. | |
| 124 | 2221 |
| 2222 Make sure that your load-path and your $EMACSLOADPATH environment | |
| 2223 variable are not pointing at an Emacs18 lisp directory. This will | |
| 2224 cripple emacs. | |
| 88 | 2225 |
| 124 | 2226 ** Some packages that worked before now cause the error |
| 223 | 2227 Wrong type argument: arrayp, #<face ... > |
| 124 | 2228 |
| 197 | 2229 Code which uses the `face' accessor functions must be recompiled with |
| 2230 xemacs 19.9 or later. The functions whose callers must be recompiled | |
| 2231 are: face-font, face-foreground, face-background, | |
| 2232 face-background-pixmap, and face-underline-p. The .elc files | |
| 2233 generated by version 19.9 will work in 19.6 and 19.8, but older .elc | |
| 2234 files which contain calls to these functions will not work in 19.9. | |
| 124 | 2235 |
| 2236 ** Signaling: (error "Byte code stack underflow (byte compiler bug), pc 38") | |
| 88 | 2237 |
| 120 | 2238 This error is given when XEmacs 20 is compiled without MULE support |
| 88 | 2239 but is attempting to load a .elc which requires MULE support. The fix |
| 2240 is to rebytecompile the offending file. | |
| 2241 | |
| 124 | 2242 ** Signaling: (wrong-type-argument ...) when loading mail-abbrevs |
| 88 | 2243 |
| 197 | 2244 The is seen when installing the Insidious Big Brother Data Base (bbdb) |
| 2245 which includes an outdated copy of mail-abbrevs.el. Remove the copy | |
| 2246 that comes with bbdb and use the one that comes with XEmacs. | |
| 2247 | |
| 144 | 2248 |
| 2249 * MULE issues | |
| 197 | 2250 ============= |
| 144 | 2251 |
| 223 | 2252 ** A reminder: XEmacs/Mule work does not currently receive *any* |
| 2253 funding, and all work is done by volunteers. If you think you can | |
| 2254 help, please contact the XEmacs maintainers. | |
| 2255 | |
| 278 | 2256 ** XEmacs/Mule doesn't support TTY's satisfactorily. |
| 223 | 2257 |
| 2258 This is a major problem, which we plan to address in a future release | |
| 2259 of XEmacs. Basically, XEmacs should have primitives to be told | |
| 2260 whether the terminal can handle international output, and which | |
| 2261 locale. Also, it should be able to do approximations of characters to | |
| 2262 the nearest supported by the locale. | |
| 2263 | |
| 197 | 2264 ** Internationalized (Asian) Isearch doesn't work. |
| 144 | 2265 |
| 2266 Currently, Isearch doesn't directly support any of the input methods | |
| 2267 that are not XIM based (like egg, canna and quail) (and there are | |
| 223 | 2268 potential problems with XIM version too...). If you're using egg |
| 2269 there is a workaround. Hitting <RET> right after C-s to invoke | |
| 2270 Isearch will put Isearch in string mode, where a complete string can | |
| 2271 be typed into the minibuffer and then processed by Isearch afterwards. | |
| 2272 Since egg is now supported in the minibuffer using string mode you can | |
| 2273 now use egg to input your Japanese, Korean or Chinese string, then hit | |
| 2274 return to send that to Isearch and then use standard Isearch commands | |
| 2275 from there. | |
| 144 | 2276 |
| 223 | 2277 ** Using egg and mousing around while in 'fence' mode screws up my |
| 2278 buffer. | |
| 144 | 2279 |
| 2280 Don't do this. The fence modes of egg and canna are currently very | |
| 2281 modal, and messing with where they expect point to be and what they | |
| 2282 think is the current buffer is just asking for trouble. If you're | |
| 2283 lucky they will realize that something is awry, and simply delete the | |
| 2284 fence, but worst case can trash other buffers too. We've tried to | |
| 2285 protect against this where we can, but there still are many ways to | |
| 2286 shoot yourself in the foot. So just finish what you are typing into | |
| 2287 the fence before reaching for the mouse. | |
| 223 | 2288 |
| 2289 ** Not all languages in Quail are supported like Devanagari and Indian | |
| 2290 languages, Lao and Tibetan. | |
| 2291 | |
| 2292 Quail requires more work and testing. Although it has been ported to | |
| 2293 XEmacs, it works really well for Japanese and for the European | |
| 2294 languages. | |
| 2295 | |
| 2296 ** Right-to-left mode is not yet implemented, so languages like | |
| 2297 Arabic, Hebrew and Thai don't work. | |
| 2298 | |
| 2299 Getting this right requires more work. It may be implemented in a | |
| 2300 future XEmacs version, but don't hold your breath. If you know | |
| 2301 someone who is ready to implement this, please let us know. | |
| 2302 | |
| 2303 ** We need more developers and native language testers. It's extremely | |
| 2304 difficult (and not particularly productive) to address languages that | |
| 2305 nobody is using and testing. | |
| 2306 | |
| 2307 ** The kWnn and cWnn support for Chinese and Korean needs developers | |
| 2308 and testers. It probably doesn't work. | |
| 2309 | |
| 2310 ** There are no `native XEmacs' TUTORIALs for any Asian languages, | |
| 454 | 2311 including Japanese. FSF Emacs and XEmacs tutorials are quite similar, |
| 223 | 2312 so it should be sufficient to skim through the differences and apply |
| 2313 them to the Japanese version. | |
| 2314 | |
| 2315 ** We only have localized menus translated for Japanese, and the | |
| 2316 Japanese menus are developing bitrot (the Mule menu appears in | |
| 2317 English). | |
| 2318 | |
| 2319 ** XIM is untested for any language other than Japanese. |