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