Mercurial > emacs
comparison etc/PROBLEMS @ 89971:cce1c0ee76ee
Revision: miles@gnu.org--gnu-2004/emacs--unicode--0--patch-36
Merge from emacs--cvs-trunk--0, emacs--gnus--5.10, gnus--rel--5.10
Patches applied:
* miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-523
Merge from emacs--gnus--5.10, gnus--rel--5.10
* miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-524
- miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-534
Update from CVS
* miles@gnu.org--gnu-2004/emacs--gnus--5.10--base-0
tag of miles@gnu.org--gnu-2004/emacs--cvs-trunk--0--patch-464
* miles@gnu.org--gnu-2004/emacs--gnus--5.10--patch-1
Import from CVS branch gnus-5_10-branch
* miles@gnu.org--gnu-2004/emacs--gnus--5.10--patch-2
Merge from lorentey@elte.hu--2004/emacs--multi-tty--0, emacs--cvs-trunk--0
* miles@gnu.org--gnu-2004/emacs--gnus--5.10--patch-3
Merge from gnus--rel--5.10
* miles@gnu.org--gnu-2004/emacs--gnus--5.10--patch-4
Merge from gnus--rel--5.10
* miles@gnu.org--gnu-2004/gnus--rel--5.10--patch-18
Update from CVS
* miles@gnu.org--gnu-2004/gnus--rel--5.10--patch-19
Remove autoconf-generated files from archive
* miles@gnu.org--gnu-2004/gnus--rel--5.10--patch-20
Update from CVS
author | Miles Bader <miles@gnu.org> |
---|---|
date | Thu, 09 Sep 2004 09:36:36 +0000 |
parents | d8411455de48 ce4c0cb926e3 |
children | e23928ac5a97 |
comparison
equal
deleted
inserted
replaced
89970:a849e5779b8c | 89971:cce1c0ee76ee |
---|---|
1 This file describes various problems that have been encountered | 1 This file describes various problems that have been encountered |
2 in compiling, installing and running GNU Emacs. Try doing Ctl t | 2 in compiling, installing and running GNU Emacs. Try doing Ctl-C Ctl-t |
3 and browsing through the outline headers. | 3 and browsing through the outline headers. |
4 | 4 |
5 * Mule-UCS doesn't work in Emacs 22. | 5 * Mule-UCS doesn't work in Emacs 22. |
6 | 6 |
7 It's completely redundant now, as far as we know. | 7 It's completely redundant now, as far as we know. |
157 prevent the problem by using a suitable shell command (often `ulimit') | 157 prevent the problem by using a suitable shell command (often `ulimit') |
158 to raise the stack size limit before you run Emacs. | 158 to raise the stack size limit before you run Emacs. |
159 | 159 |
160 Patches to raise the stack size limit automatically in `main' | 160 Patches to raise the stack size limit automatically in `main' |
161 (src/emacs.c) on various systems would be greatly appreciated. | 161 (src/emacs.c) on various systems would be greatly appreciated. |
162 | |
163 ** Emacs crashes with SIGBUS or SIGSEGV on HPUX 9 after you delete a frame. | |
164 | |
165 We think this is due to a bug in the X libraries provided by HP. With | |
166 the alternative X libraries in /usr/contrib/mitX11R5/lib, the problem | |
167 does not happen. | |
168 | |
169 ** Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame. | |
170 | |
171 We suspect that this is a similar bug in the X libraries provided by | |
172 Sun. There is a report that one of these patches fixes the bug and | |
173 makes the problem stop: | |
174 | |
175 105216-01 105393-01 105518-01 105621-01 105665-01 105615-02 105216-02 | |
176 105667-01 105401-08 105615-03 105621-02 105686-02 105736-01 105755-03 | |
177 106033-01 105379-01 105786-01 105181-04 105379-03 105786-04 105845-01 | |
178 105284-05 105669-02 105837-01 105837-02 105558-01 106125-02 105407-01 | |
179 | |
180 Another person using a newer system (kernel patch level Generic_105181-06) | |
181 suspects that the bug was fixed by one of these more recent patches: | |
182 | |
183 106040-07 SunOS 5.6: X Input & Output Method patch | |
184 106222-01 OpenWindows 3.6: filemgr (ff.core) fixes | |
185 105284-12 Motif 1.2.7: sparc Runtime library patch | |
186 | 162 |
187 ** Error message `Symbol's value as variable is void: x', followed by | 163 ** Error message `Symbol's value as variable is void: x', followed by |
188 a segmentation fault and core dump. | 164 a segmentation fault and core dump. |
189 | 165 |
190 This has been tracked to a bug in tar! People report that tar erroneously | 166 This has been tracked to a bug in tar! People report that tar erroneously |
1274 | 1250 |
1275 To check thoroughly for such resource specifications, use `xrdb | 1251 To check thoroughly for such resource specifications, use `xrdb |
1276 -query' to see what resources the X server records, and also look at | 1252 -query' to see what resources the X server records, and also look at |
1277 the user's ~/.Xdefaults and ~/.Xdefaults-* files. | 1253 the user's ~/.Xdefaults and ~/.Xdefaults-* files. |
1278 | 1254 |
1279 *** --with-x-toolkit version crashes when used with shared libraries. | |
1280 | |
1281 On some systems, including Sunos 4 and DGUX 5.4.2 and perhaps others, | |
1282 unexec doesn't work properly with the shared library for the X | |
1283 toolkit. You might be able to work around this by using a nonshared | |
1284 libXt.a library. The real fix is to upgrade the various versions of | |
1285 unexec and/or ralloc. We think this has been fixed on Sunos 4 | |
1286 and Solaris in version 19.29. | |
1287 | |
1288 *** Emacs running under X Windows does not handle mouse clicks. | 1255 *** Emacs running under X Windows does not handle mouse clicks. |
1289 *** `emacs -geometry 80x20' finds a file named `80x20'. | 1256 *** `emacs -geometry 80x20' finds a file named `80x20'. |
1290 | 1257 |
1291 One cause of such problems is having (setq term-file-prefix nil) in | 1258 One cause of such problems is having (setq term-file-prefix nil) in |
1292 your .emacs file. Another cause is a bad value of EMACSLOADPATH in | 1259 your .emacs file. Another cause is a bad value of EMACSLOADPATH in |
1796 does not get a response from the server within a timeout whose default | 1763 does not get a response from the server within a timeout whose default |
1797 value is just ten seconds. | 1764 value is just ten seconds. |
1798 | 1765 |
1799 If this happens to you, extend the timeout period. | 1766 If this happens to you, extend the timeout period. |
1800 | 1767 |
1801 *** HP/UX: Emacs is slow using X11R5. | |
1802 | |
1803 This happens if you use the MIT versions of the X libraries--it | |
1804 doesn't run as fast as HP's version. People sometimes use the version | |
1805 because they see the HP version doesn't have the libraries libXaw.a, | |
1806 libXmu.a, libXext.a and others. HP/UX normally doesn't come with | |
1807 those libraries installed. To get good performance, you need to | |
1808 install them and rebuild Emacs. | |
1809 | |
1810 *** HP/UX: The right Alt key works wrong on German HP keyboards (and perhaps | 1768 *** HP/UX: The right Alt key works wrong on German HP keyboards (and perhaps |
1811 other non-English HP keyboards too). | 1769 other non-English HP keyboards too). |
1812 | 1770 |
1813 This is because HP-UX defines the modifiers wrong in X. Here is a | 1771 This is because HP-UX defines the modifiers wrong in X. Here is a |
1814 shell script to fix the problem; be sure that it is run after VUE | 1772 shell script to fix the problem; be sure that it is run after VUE |
1851 keysym Meta_R = Mode_switch | 1809 keysym Meta_R = Mode_switch |
1852 add mod2 = Mode_switch | 1810 add mod2 = Mode_switch |
1853 EOF | 1811 EOF |
1854 -------------------------------- | 1812 -------------------------------- |
1855 | 1813 |
1856 *** HP/UX: Large file support is disabled. | |
1857 | |
1858 See the comments in src/s/hpux10.h. | |
1859 | |
1860 *** HP/UX 11.0: Emacs makes HP/UX 11.0 crash. | 1814 *** HP/UX 11.0: Emacs makes HP/UX 11.0 crash. |
1861 | 1815 |
1862 This is a bug in HPUX; HPUX patch PHKL_16260 is said to fix it. | 1816 This is a bug in HPUX; HPUX patch PHKL_16260 is said to fix it. |
1863 | 1817 |
1864 ** AIX | 1818 ** AIX |
1874 | 1828 |
1875 *aixterm.Translations: #override <Key>BackSpace: string(0x7f) | 1829 *aixterm.Translations: #override <Key>BackSpace: string(0x7f) |
1876 aixterm*ttyModes: erase ^? | 1830 aixterm*ttyModes: erase ^? |
1877 | 1831 |
1878 This makes your Backspace key send DEL (ASCII 127). | 1832 This makes your Backspace key send DEL (ASCII 127). |
1879 | |
1880 *** AIX: You get this message when running Emacs: | |
1881 | |
1882 Could not load program emacs | |
1883 Symbol smtcheckinit in csh is undefined | |
1884 Error was: Exec format error | |
1885 | |
1886 or this one: | |
1887 | |
1888 Could not load program .emacs | |
1889 Symbol _system_con in csh is undefined | |
1890 Symbol _fp_trapsta in csh is undefined | |
1891 Error was: Exec format error | |
1892 | |
1893 These can happen when you try to run on AIX 3.2.5 a program that was | |
1894 compiled with 3.2.4. The fix is to recompile. | |
1895 | |
1896 *** AIX 3.2.4: Releasing Ctrl/Act key has no effect, if Shift is down. | |
1897 | |
1898 Due to a feature of AIX, pressing or releasing the Ctrl/Act key is | |
1899 ignored when the Shift, Alt or AltGr keys are held down. This can | |
1900 lead to the keyboard being "control-locked"--ordinary letters are | |
1901 treated as control characters. | |
1902 | |
1903 You can get out of this "control-locked" state by pressing and | |
1904 releasing Ctrl/Act while not pressing or holding any other keys. | |
1905 | |
1906 *** AIX 4.2: Emacs gets a segmentation fault at startup. | |
1907 | |
1908 If you are using IBM's xlc compiler, compile emacs.c | |
1909 without optimization; that should avoid the problem. | |
1910 | 1833 |
1911 *** AIX: If linking fails because libXbsd isn't found, check if you | 1834 *** AIX: If linking fails because libXbsd isn't found, check if you |
1912 are compiling with the system's `cc' and CFLAGS containing `-O5'. If | 1835 are compiling with the system's `cc' and CFLAGS containing `-O5'. If |
1913 so, you have hit a compiler bug. Please make sure to re-configure | 1836 so, you have hit a compiler bug. Please make sure to re-configure |
1914 Emacs so that it isn't compiled with `-O5'. | 1837 Emacs so that it isn't compiled with `-O5'. |
1942 On a Sun, running Emacs on one machine with the X server on another | 1865 On a Sun, running Emacs on one machine with the X server on another |
1943 may not work if you have used the unshared system libraries. This | 1866 may not work if you have used the unshared system libraries. This |
1944 is because the unshared libraries fail to use YP for host name lookup. | 1867 is because the unshared libraries fail to use YP for host name lookup. |
1945 As a result, the host name you specify may not be recognized. | 1868 As a result, the host name you specify may not be recognized. |
1946 | 1869 |
1947 *** Emacs reports a BadAtom error (from X) running on Solaris 7 or 8. | 1870 *** Solaris 2,6: Emacs crashes with SIGBUS or SIGSEGV on Solaris after you delete a frame. |
1871 | |
1872 We suspect that this is a bug in the X libraries provided by | |
1873 Sun. There is a report that one of these patches fixes the bug and | |
1874 makes the problem stop: | |
1875 | |
1876 105216-01 105393-01 105518-01 105621-01 105665-01 105615-02 105216-02 | |
1877 105667-01 105401-08 105615-03 105621-02 105686-02 105736-01 105755-03 | |
1878 106033-01 105379-01 105786-01 105181-04 105379-03 105786-04 105845-01 | |
1879 105284-05 105669-02 105837-01 105837-02 105558-01 106125-02 105407-01 | |
1880 | |
1881 Another person using a newer system (kernel patch level Generic_105181-06) | |
1882 suspects that the bug was fixed by one of these more recent patches: | |
1883 | |
1884 106040-07 SunOS 5.6: X Input & Output Method patch | |
1885 106222-01 OpenWindows 3.6: filemgr (ff.core) fixes | |
1886 105284-12 Motif 1.2.7: sparc Runtime library patch | |
1887 | |
1888 *** Solaris 7 or 8: Emacs reports a BadAtom error (from X) | |
1948 | 1889 |
1949 This happens when Emacs was built on some other version of Solaris. | 1890 This happens when Emacs was built on some other version of Solaris. |
1950 Rebuild it on Solaris 8. | 1891 Rebuild it on Solaris 8. |
1951 | 1892 |
1893 *** When using M-x dbx with the SparcWorks debugger, the `up' and `down' | |
1894 commands do not move the arrow in Emacs. | |
1895 | |
1896 You can fix this by adding the following line to `~/.dbxinit': | |
1897 | |
1898 dbxenv output_short_file_name off | |
1899 | |
1952 *** On Solaris, CTRL-t is ignored by Emacs when you use | 1900 *** On Solaris, CTRL-t is ignored by Emacs when you use |
1953 the fr.ISO-8859-15 locale (and maybe other related locales). | 1901 the fr.ISO-8859-15 locale (and maybe other related locales). |
1954 | 1902 |
1955 You can fix this by editing the file: | 1903 You can fix this by editing the file: |
1956 | 1904 |
1964 | 1912 |
1965 Ctrl<T> <quotedbl> <Y> : "\276" threequarters | 1913 Ctrl<T> <quotedbl> <Y> : "\276" threequarters |
1966 | 1914 |
1967 Note the lower case <t>. Changing this line should make C-t work. | 1915 Note the lower case <t>. Changing this line should make C-t work. |
1968 | 1916 |
1969 *** When using M-x dbx with the SparcWorks debugger, the `up' and `down' | |
1970 commands do not move the arrow in Emacs. | |
1971 | |
1972 You can fix this by adding the following line to `~/.dbxinit': | |
1973 | |
1974 dbxenv output_short_file_name off | |
1975 | |
1976 ** Irix | 1917 ** Irix |
1977 | 1918 |
1978 *** Irix 5.2: unexelfsgi.c can't find cmplrs/stsupport.h. | |
1979 | |
1980 The file cmplrs/stsupport.h was included in the wrong file set in the | |
1981 Irix 5.2 distribution. You can find it in the optional fileset | |
1982 compiler_dev, or copy it from some other Irix 5.2 system. A kludgy | |
1983 workaround is to change unexelfsgi.c to include sym.h instead of | |
1984 syms.h. | |
1985 | |
1986 *** Irix 5.3: "out of virtual swap space". | |
1987 | |
1988 This message occurs when the system runs out of swap space due to too | |
1989 many large programs running. The solution is either to provide more | |
1990 swap space or to reduce the number of large programs being run. You | |
1991 can check the current status of the swap space by executing the | |
1992 command `swap -l'. | |
1993 | |
1994 You can increase swap space by changing the file /etc/fstab. Adding a | |
1995 line like this: | |
1996 | |
1997 /usr/swap/swap.more swap swap pri=3 0 0 | |
1998 | |
1999 where /usr/swap/swap.more is a file previously created (for instance | |
2000 by using /etc/mkfile), will increase the swap space by the size of | |
2001 that file. Execute `swap -m' or reboot the machine to activate the | |
2002 new swap area. See the manpages for `swap' and `fstab' for further | |
2003 information. | |
2004 | |
2005 The objectserver daemon can use up lots of memory because it can be | |
2006 swamped with NIS information. It collects information about all users | |
2007 on the network that can log on to the host. | |
2008 | |
2009 If you want to disable the objectserver completely, you can execute | |
2010 the command `chkconfig objectserver off' and reboot. That may disable | |
2011 some of the window system functionality, such as responding CDROM | |
2012 icons. | |
2013 | |
2014 You can also remove NIS support from the objectserver. The SGI `admin' | |
2015 FAQ has a detailed description on how to do that; see question 35 | |
2016 ("Why isn't the objectserver working?"). The admin FAQ can be found at | |
2017 ftp://viz.tamu.edu/pub/sgi/faq/. | |
2018 | |
2019 *** Irix 5.3: Emacs crashes in utmpname. | |
2020 | |
2021 This problem is fixed in Patch 3175 for Irix 5.3. | |
2022 It is also fixed in Irix versions 6.2 and up. | |
2023 | |
2024 *** Irix 6.0: Make tries (and fails) to build a program named unexelfsgi. | |
2025 | |
2026 A compiler bug inserts spaces into the string "unexelfsgi . o" | |
2027 in src/Makefile. Edit src/Makefile, after configure is run, | |
2028 find that string, and take out the spaces. | |
2029 | |
2030 Compiler fixes in Irix 6.0.1 should eliminate this problem. | |
2031 | |
2032 *** Irix 6.5: Emacs crashes on the SGI R10K, when compiled with GCC. | 1919 *** Irix 6.5: Emacs crashes on the SGI R10K, when compiled with GCC. |
2033 | 1920 |
2034 This seems to be fixed in GCC 2.95. | 1921 This seems to be fixed in GCC 2.95. |
2035 | 1922 |
2036 *** Trouble using ptys on IRIX, or running out of ptys. | 1923 *** Irix: Trouble using ptys, or running out of ptys. |
2037 | 1924 |
2038 The program mkpts (which may be in `/usr/adm' or `/usr/sbin') needs to | 1925 The program mkpts (which may be in `/usr/adm' or `/usr/sbin') needs to |
2039 be set-UID to root, or non-root programs like Emacs will not be able | 1926 be set-UID to root, or non-root programs like Emacs will not be able |
2040 to allocate ptys reliably. | 1927 to allocate ptys reliably. |
2041 | |
2042 ** SCO Unix and UnixWare | |
2043 | |
2044 *** SCO 3.2v4: Unusable default font. | |
2045 | |
2046 The Open Desktop environment comes with default X resource settings | |
2047 that tell Emacs to use a variable-width font. Emacs cannot use such | |
2048 fonts, so it does not work. | |
2049 | |
2050 This is caused by the file /usr/lib/X11/app-defaults/ScoTerm, which is | |
2051 the application-specific resource file for the `scoterm' terminal | |
2052 emulator program. It contains several extremely general X resources | |
2053 that affect other programs besides `scoterm'. In particular, these | |
2054 resources affect Emacs also: | |
2055 | |
2056 *Font: -*-helvetica-medium-r-*--12-*-p-* | |
2057 *Background: scoBackground | |
2058 *Foreground: scoForeground | |
2059 | |
2060 The best solution is to create an application-specific resource file for | |
2061 Emacs, /usr/lib/X11/sco/startup/Emacs, with the following contents: | |
2062 | |
2063 Emacs*Font: -*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1 | |
2064 Emacs*Background: white | |
2065 Emacs*Foreground: black | |
2066 | |
2067 (These settings mimic the Emacs defaults, but you can change them to | |
2068 suit your needs.) This resource file is only read when the X server | |
2069 starts up, so you should restart it by logging out of the Open Desktop | |
2070 environment or by running `scologin stop; scologin start` from the shell | |
2071 as root. Alternatively, you can put these settings in the | |
2072 /usr/lib/X11/app-defaults/Emacs resource file and simply restart Emacs, | |
2073 but then they will not affect remote invocations of Emacs that use the | |
2074 Open Desktop display. | |
2075 | |
2076 These resource files are not normally shared across a network of SCO | |
2077 machines; you must create the file on each machine individually. | |
2078 | |
2079 *** Regular expressions matching bugs on SCO systems. | |
2080 | |
2081 On SCO, there are problems in regexp matching when Emacs is compiled | |
2082 with the system compiler. The compiler version is "Microsoft C | |
2083 version 6", SCO 4.2.0h Dev Sys Maintenance Supplement 01/06/93; Quick | |
2084 C Compiler Version 1.00.46 (Beta). The solution is to compile with | |
2085 GCC. | |
2086 | |
2087 *** UnixWare 2.1: Error 12 (virtual memory exceeded) when dumping Emacs. | |
2088 | |
2089 Paul Abrahams (abrahams@acm.org) reports that with the installed | |
2090 virtual memory settings for UnixWare 2.1.2, an Error 12 occurs during | |
2091 the "make" that builds Emacs, when running temacs to dump emacs. That | |
2092 error indicates that the per-process virtual memory limit has been | |
2093 exceeded. The default limit is probably 32MB. Raising the virtual | |
2094 memory limit to 40MB should make it possible to finish building Emacs. | |
2095 | |
2096 You can do this with the command `ulimit' (sh) or `limit' (csh). | |
2097 But you have to be root to do it. | |
2098 | |
2099 According to Martin Sohnius, you can also retune this in the kernel: | |
2100 | |
2101 # /etc/conf/bin/idtune SDATLIM 33554432 ## soft data size limit | |
2102 # /etc/conf/bin/idtune HDATLIM 33554432 ## hard " | |
2103 # /etc/conf/bin/idtune SVMMSIZE unlimited ## soft process size limit | |
2104 # /etc/conf/bin/idtune HVMMSIZE unlimited ## hard " | |
2105 # /etc/conf/bin/idbuild -B | |
2106 | |
2107 (He recommends you not change the stack limit, though.) | |
2108 These changes take effect when you reboot. | |
2109 | 1928 |
2110 * Runtime problems specific to MS-Windows | 1929 * Runtime problems specific to MS-Windows |
2111 | 1930 |
2112 ** Emacs exits with "X protocol error" when run with an X server for MS-Windows. | 1931 ** Emacs exits with "X protocol error" when run with an X server for MS-Windows. |
2113 | 1932 |
2155 The %b specifier for format-time-string does not produce abbreviated | 1974 The %b specifier for format-time-string does not produce abbreviated |
2156 month names with consistent widths for some locales on some versions | 1975 month names with consistent widths for some locales on some versions |
2157 of Windows. This is caused by a deficiency in the underlying system | 1976 of Windows. This is caused by a deficiency in the underlying system |
2158 library function. | 1977 library function. |
2159 | 1978 |
2160 ** Problems running Perl under Emacs on MS-Windows NT/95. | 1979 ** Typing Alt-Shift has strange effects on MS-Windows. |
1980 | |
1981 This combination of keys is a command to change keyboard layout. If | |
1982 you proceed to type another non-modifier key before you let go of Alt | |
1983 and Shift, the Alt and Shift act as modifiers in the usual way. A | |
1984 more permanent work around is to change it to another key combination, | |
1985 or disable it in the keyboard control panel. | |
1986 | |
1987 ** Interrupting Cygwin port of Bash from Emacs doesn't work. | |
1988 | |
1989 Cygwin 1.x builds of the ported Bash cannot be interrupted from the | |
1990 MS-Windows version of Emacs. This is due to some change in the Bash | |
1991 port or in the Cygwin library which apparently make Bash ignore the | |
1992 keyboard interrupt event sent by Emacs to Bash. (Older Cygwin ports | |
1993 of Bash, up to b20.1, did receive SIGINT from Emacs.) | |
1994 | |
1995 ** Accessing remote files with ange-ftp hangs the MS-Windows version of Emacs. | |
1996 | |
1997 If the FTP client is the Cygwin port of GNU `ftp', this appears to be | |
1998 due to some bug in the Cygwin DLL or some incompatibility between it | |
1999 and the implementation of asynchronous subprocesses in the Windows | |
2000 port of Emacs. Specifically, some parts of the FTP server responses | |
2001 are not flushed out, apparently due to buffering issues, which | |
2002 confuses ange-ftp. | |
2003 | |
2004 The solution is to downgrade to an older version of the Cygwin DLL | |
2005 (version 1.3.2 was reported to solve the problem), or use the stock | |
2006 Windows FTP client, usually found in the `C:\WINDOWS' or 'C:\WINNT' | |
2007 directory. To force ange-ftp use the stock Windows client, set the | |
2008 variable `ange-ftp-ftp-program-name' to the absolute file name of the | |
2009 client's executable. For example: | |
2010 | |
2011 (setq ange-ftp-ftp-program-name "c:/windows/ftp.exe") | |
2012 | |
2013 If you want to stick with the Cygwin FTP client, you can work around | |
2014 this problem by putting this in your `.emacs' file: | |
2015 | |
2016 (setq ange-ftp-ftp-program-args '("-i" "-n" "-g" "-v" "--prompt" "") | |
2017 | |
2018 ** lpr commands don't work on MS-Windows with some cheap printers. | |
2019 | |
2020 This problem may also strike other platforms, but the solution is | |
2021 likely to be a global one, and not Emacs specific. | |
2022 | |
2023 Many cheap inkjet, and even some cheap laser printers, do not | |
2024 print plain text anymore, they will only print through graphical | |
2025 printer drivers. A workaround on MS-Windows is to use Windows' basic | |
2026 built in editor to print (this is possibly the only useful purpose it | |
2027 has): | |
2028 | |
2029 (setq printer-name "") ;; notepad takes the default | |
2030 (setq lpr-command "notepad") ;; notepad | |
2031 (setq lpr-switches nil) ;; not needed | |
2032 (setq lpr-printer-switch "/P") ;; run notepad as batch printer | |
2033 | |
2034 ** Antivirus software interacts badly with the MS-Windows version of Emacs. | |
2035 | |
2036 The usual manifestation of these problems is that subprocesses don't | |
2037 work or even wedge the entire system. In particular, "M-x shell RET" | |
2038 was reported to fail to work. But other commands also sometimes don't | |
2039 work when an antivirus package is installed. | |
2040 | |
2041 The solution is to switch the antivirus software to a less aggressive | |
2042 mode (e.g., disable the ``auto-protect'' feature), or even uninstall | |
2043 or disable it entirely. | |
2044 | |
2045 ** Pressing the mouse button on MS-Windows does not give a mouse-2 event. | |
2046 | |
2047 This is usually a problem with the mouse driver. Because most Windows | |
2048 programs do not do anything useful with the middle mouse button, many | |
2049 mouse drivers allow you to define the wheel press to do something | |
2050 different. Some drivers do not even have the option to generate a | |
2051 middle button press. In such cases, setting the wheel press to | |
2052 "scroll" sometimes works if you press the button twice. Trying a | |
2053 generic mouse driver might help. | |
2054 | |
2055 ** Scrolling the mouse wheel on MS-Windows always scrolls the top window. | |
2056 | |
2057 This is another common problem with mouse drivers. Instead of | |
2058 generating scroll events, some mouse drivers try to fake scroll bar | |
2059 movement. But they are not intelligent enough to handle multiple | |
2060 scroll bars within a frame. Trying a generic mouse driver might help. | |
2061 | |
2062 ** Mail sent through Microsoft Exchange in some encodings appears to be | |
2063 mangled and is not seen correctly in Rmail or Gnus. We don't know | |
2064 exactly what happens, but it isn't an Emacs problem in cases we've | |
2065 seen. | |
2066 | |
2067 ** On MS-Windows, you cannot use the right-hand ALT key and the left-hand | |
2068 CTRL key together to type a Control-Meta character. | |
2069 | |
2070 This is a consequence of a misfeature beyond Emacs's control. | |
2071 | |
2072 Under Windows, the AltGr key on international keyboards generates key | |
2073 events with the modifiers Right-Alt and Left-Ctrl. Since Emacs cannot | |
2074 distinguish AltGr from an explicit Right-Alt and Left-Ctrl | |
2075 combination, whenever it sees Right-Alt and Left-Ctrl it assumes that | |
2076 AltGr has been pressed. The variable `w32-recognize-altgr' can be set | |
2077 to nil to tell Emacs that AltGr is really Ctrl and Alt. | |
2078 | |
2079 ** Under some X-servers running on MS-Windows, Emacs' display is incorrect. | |
2080 | |
2081 The symptoms are that Emacs does not completely erase blank areas of the | |
2082 screen during scrolling or some other screen operations (e.g., selective | |
2083 display or when killing a region). M-x recenter will cause the screen | |
2084 to be completely redisplayed and the "extra" characters will disappear. | |
2085 | |
2086 This is known to occur under Exceed 6, and possibly earlier versions | |
2087 as well; it is reportedly solved in version 6.2.0.16 and later. The | |
2088 problem lies in the X-server settings. | |
2089 | |
2090 There are reports that you can solve the problem with Exceed by | |
2091 running `Xconfig' from within NT, choosing "X selection", then | |
2092 un-checking the boxes "auto-copy X selection" and "auto-paste to X | |
2093 selection". | |
2094 | |
2095 Of this does not work, please inform bug-gnu-emacs@gnu.org. Then | |
2096 please call support for your X-server and see if you can get a fix. | |
2097 If you do, please send it to bug-gnu-emacs@gnu.org so we can list it | |
2098 here. | |
2099 | |
2100 * Build-time problems | |
2101 | |
2102 ** Configuration | |
2103 | |
2104 *** The `configure' script doesn't find the jpeg library. | |
2105 | |
2106 There are reports that this happens on some systems because the linker | |
2107 by default only looks for shared libraries, but jpeg distribution by | |
2108 default only installs a nonshared version of the library, `libjpeg.a'. | |
2109 | |
2110 If this is the problem, you can configure the jpeg library with the | |
2111 `--enable-shared' option and then rebuild libjpeg. This produces a | |
2112 shared version of libjpeg, which you need to install. Finally, rerun | |
2113 the Emacs configure script, which should now find the jpeg library. | |
2114 Alternatively, modify the generated src/Makefile to link the .a file | |
2115 explicitly, and edit src/config.h to define HAVE_JPEG. | |
2116 | |
2117 ** Compilation | |
2118 | |
2119 *** Building Emacs over NFS fails with ``Text file busy''. | |
2120 | |
2121 This was reported to happen when building Emacs on a GNU/Linux system | |
2122 (RedHat Linux 6.2) using a build directory automounted from Solaris | |
2123 (SunOS 5.6) file server, but it might not be limited to that | |
2124 configuration alone. Presumably, the NFS server doesn't commit the | |
2125 files' data to disk quickly enough, and the Emacs executable file is | |
2126 left ``busy'' for several seconds after Emacs has finished dumping | |
2127 itself. This causes the subsequent commands which invoke the dumped | |
2128 Emacs executable to fail with the above message. | |
2129 | |
2130 In some of these cases, a time skew between the NFS server and the | |
2131 machine where Emacs is built is detected and reported by GNU Make | |
2132 (it says that some of the files have modification time in the future). | |
2133 This might be a symptom of NFS-related problems. | |
2134 | |
2135 If the NFS server runs on Solaris, apply the Solaris patch 105379-05 | |
2136 (Sunos 5.6: /kernel/misc/nfssrv patch). If that doesn't work, or if | |
2137 you have a different version of the OS or the NFS server, you can | |
2138 force the NFS server to use 1KB blocks, which was reported to fix the | |
2139 problem albeit at a price of slowing down file I/O. You can force 1KB | |
2140 blocks by specifying the "-o rsize=1024,wsize=1024" options to the | |
2141 `mount' command, or by adding ",rsize=1024,wsize=1024" to the mount | |
2142 options in the appropriate system configuration file, such as | |
2143 `/etc/auto.home'. | |
2144 | |
2145 Alternatively, when Make fails due to this problem, you could wait for | |
2146 a few seconds and then invoke Make again. In one particular case, | |
2147 waiting for 10 or more seconds between the two Make invocations seemed | |
2148 to work around the problem. | |
2149 | |
2150 Similar problems can happen if your machine NFS-mounts a directory | |
2151 onto itself. Suppose the Emacs sources live in `/usr/local/src' and | |
2152 you are working on the host called `marvin'. Then an entry in the | |
2153 `/etc/fstab' file like the following is asking for trouble: | |
2154 | |
2155 marvin:/usr/local/src /usr/local/src ...options.omitted... | |
2156 | |
2157 The solution is to remove this line from `etc/fstab'. | |
2158 | |
2159 *** Building Emacs with GCC 2.9x fails in the `src' directory. | |
2160 | |
2161 This may happen if you use a development version of GNU `cpp' from one | |
2162 of the GCC snapshots between Oct 2000 and Feb 2001, or from a released | |
2163 version of GCC newer than 2.95.2 which was prepared around those | |
2164 dates; similar problems were reported with some snapshots of GCC 3.1 | |
2165 around Sep 30 2001. The preprocessor in those versions is | |
2166 incompatible with a traditional Unix cpp (e.g., it expands ".." into | |
2167 ". .", which breaks relative file names that reference the parent | |
2168 directory; or inserts TAB characters before lines that set Make | |
2169 variables). | |
2170 | |
2171 The solution is to make sure the preprocessor is run with the | |
2172 `-traditional' option. The `configure' script does that automatically | |
2173 when it detects the known problems in your cpp, but you might hit some | |
2174 unknown ones. To force the `configure' script to use `-traditional', | |
2175 run the script like this: | |
2176 | |
2177 CPP='gcc -E -traditional' ./configure ... | |
2178 | |
2179 (replace the ellipsis "..." with any additional arguments you pass to | |
2180 the script). | |
2181 | |
2182 Note that this problem does not pertain to the MS-Windows port of | |
2183 Emacs, since it doesn't use the preprocessor to generate Makefiles. | |
2184 | |
2185 *** src/Makefile and lib-src/Makefile are truncated--most of the file missing. | |
2186 *** Compiling wakeup, in lib-src, says it can't make wakeup.c. | |
2187 | |
2188 This can happen if configure uses GNU sed version 2.03. That version | |
2189 had a bug. GNU sed version 2.05 works properly.To solve the | |
2190 problem, install the current version of GNU Sed, then rerun Emacs's | |
2191 configure script. | |
2192 | |
2193 *** Compiling lib-src says there is no rule to make test-distrib.c. | |
2194 | |
2195 This results from a bug in a VERY old version of GNU Sed. To solve | |
2196 the problem, install the current version of GNU Sed, then rerun | |
2197 Emacs's configure script. | |
2198 | |
2199 *** Building the MS-Windows port with Cygwin GCC can fail. | |
2200 | |
2201 Emacs may not build using recent Cygwin builds of GCC, such as Cygwin | |
2202 version 1.1.8, using the default configure settings. It appears to be | |
2203 necessary to specify the -mwin32 flag when compiling, and define | |
2204 __MSVCRT__, like so: | |
2205 | |
2206 configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__ | |
2207 | |
2208 *** Building the MS-Windows port fails with a CreateProcess failure. | |
2209 | |
2210 Some versions of mingw32 make on some versions of Windows do not seem | |
2211 to detect the shell correctly. Try "make SHELL=cmd.exe", or if that | |
2212 fails, try running make from Cygwin bash instead. | |
2213 | |
2214 *** Building the MS-Windows port with Leim fails in the `leim' directory. | |
2215 | |
2216 The error message might be something like this: | |
2217 | |
2218 Converting d:/emacs-21.3/leim/CXTERM-DIC/4Corner.tit to quail-package... | |
2219 Invalid ENCODE: value in TIT dictionary | |
2220 NMAKE : fatal error U1077: '"../src/obj-spd/i386/emacs.exe"' : return code | |
2221 '0xffffffff' | |
2222 Stop. | |
2223 | |
2224 This can happen if the Leim distribution is unpacked with a program | |
2225 which converts the `*.tit' files to DOS-style CR-LF text format. The | |
2226 `*.tit' files in the leim/CXTERM-DIC directory require Unix-style line | |
2227 endings to compile properly, because Emacs reads them without any code | |
2228 or EOL conversions. | |
2229 | |
2230 The solution is to make sure the program used to unpack Leim does not | |
2231 change the files' line endings behind your back. The GNU FTP site has | |
2232 in the `/gnu/emacs/windows' directory a program called `djtarnt.exe' | |
2233 which can be used to unpack `.tar.gz' and `.zip' archives without | |
2234 mangling them. | |
2235 | |
2236 *** Building `ctags' for MS-Windows with the MinGW port of GCC fails. | |
2237 | |
2238 This might happen due to a bug in the MinGW header assert.h, which | |
2239 defines the `assert' macro with a trailing semi-colon. The following | |
2240 patch to assert.h should solve this: | |
2241 | |
2242 *** include/assert.h.orig Sun Nov 7 02:41:36 1999 | |
2243 --- include/assert.h Mon Jan 29 11:49:10 2001 | |
2244 *************** | |
2245 *** 41,47 **** | |
2246 /* | |
2247 * If not debugging, assert does nothing. | |
2248 */ | |
2249 ! #define assert(x) ((void)0); | |
2250 | |
2251 #else /* debugging enabled */ | |
2252 | |
2253 --- 41,47 ---- | |
2254 /* | |
2255 * If not debugging, assert does nothing. | |
2256 */ | |
2257 ! #define assert(x) ((void)0) | |
2258 | |
2259 #else /* debugging enabled */ | |
2260 | |
2261 | |
2262 ** Linking | |
2263 | |
2264 *** Building Emacs with a system compiler fails to link because of an | |
2265 undefined symbol such as __eprintf which does not appear in Emacs. | |
2266 | |
2267 This can happen if some of the libraries linked into Emacs were built | |
2268 with GCC, but Emacs itself is being linked with a compiler other than | |
2269 GCC. Object files compiled with GCC might need some helper functions | |
2270 from libgcc.a, the library which comes with GCC, but the system | |
2271 compiler does not instruct the linker to search libgcc.a during the | |
2272 link stage. | |
2273 | |
2274 A solution is to link with GCC, like this: | |
2275 | |
2276 make CC=gcc | |
2277 | |
2278 Since the .o object files already exist, this will not recompile Emacs | |
2279 with GCC, but just restart by trying again to link temacs. | |
2280 | |
2281 *** AIX 1.3 ptf 0013: Link failure. | |
2282 | |
2283 There is a real duplicate definition of the function `_slibc_free' in | |
2284 the library /lib/libc_s.a (just do nm on it to verify). The | |
2285 workaround/fix is: | |
2286 | |
2287 cd /lib | |
2288 ar xv libc_s.a NLtmtime.o | |
2289 ar dv libc_s.a NLtmtime.o | |
2290 | |
2291 *** AIX 4.1.2: Linker error messages such as | |
2292 ld: 0711-212 SEVERE ERROR: Symbol .__quous, found in the global symbol table | |
2293 of archive /usr/lib/libIM.a, was not defined in archive member shr.o. | |
2294 | |
2295 This is a problem in libIM.a. You can work around it by executing | |
2296 these shell commands in the src subdirectory of the directory where | |
2297 you build Emacs: | |
2298 | |
2299 cp /usr/lib/libIM.a . | |
2300 chmod 664 libIM.a | |
2301 ranlib libIM.a | |
2302 | |
2303 Then change -lIM to ./libIM.a in the command to link temacs (in | |
2304 Makefile). | |
2305 | |
2306 *** Sun with acc: Link failure when using acc on a Sun. | |
2307 | |
2308 To use acc, you need additional options just before the libraries, such as | |
2309 | |
2310 /usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1 | |
2311 | |
2312 and you need to add -lansi just before -lc. | |
2313 | |
2314 The precise file names depend on the compiler version, so we | |
2315 cannot easily arrange to supply them. | |
2316 | |
2317 *** Linking says that the functions insque and remque are undefined. | |
2318 | |
2319 Change oldXMenu/Makefile by adding insque.o to the variable OBJS. | |
2320 | |
2321 *** `tparam' reported as a multiply-defined symbol when linking with ncurses. | |
2322 | |
2323 This problem results from an incompatible change in ncurses, in | |
2324 version 1.9.9e approximately. This version is unable to provide a | |
2325 definition of tparm without also defining tparam. This is also | |
2326 incompatible with Terminfo; as a result, the Emacs Terminfo support | |
2327 does not work with this version of ncurses. | |
2328 | |
2329 The fix is to install a newer version of ncurses, such as version 4.2. | |
2330 | |
2331 ** Dumping | |
2332 | |
2333 *** Linux: Segfault during `make bootstrap' under certain recent versions of the Linux kernel. | |
2334 | |
2335 With certain recent Linux kernels (like the one of Redhat Fedora Core | |
2336 1), the new "Exec-shield" functionality is enabled by default, which | |
2337 creates a different memory layout that breaks the emacs dumper. | |
2338 | |
2339 You can check the Exec-shield state like this: | |
2340 | |
2341 cat /proc/sys/kernel/exec-shield | |
2342 | |
2343 It returns 1 or 2 when Exec-shield is enabled, 0 otherwise. Please | |
2344 read your system documentation for more details on Exec-shield and | |
2345 associated commands. | |
2346 | |
2347 When Exec-shield is enabled, building Emacs will segfault during the | |
2348 execution of this command: | |
2349 | |
2350 temacs --batch --load loadup [dump|bootstrap] | |
2351 | |
2352 To work around this problem, it is necessary to temporarily disable | |
2353 Exec-shield while building Emacs, using the `setarch' command like | |
2354 this: | |
2355 | |
2356 setarch i386 ./configure <configure parameters> | |
2357 setarch i386 make <make parameters> | |
2358 | |
2359 *** Fatal signal in the command temacs -l loadup inc dump. | |
2360 | |
2361 This command is the final stage of building Emacs. It is run by the | |
2362 Makefile in the src subdirectory, or by build.com on VMS. | |
2363 | |
2364 It has been known to get fatal errors due to insufficient swapping | |
2365 space available on the machine. | |
2366 | |
2367 On 68000s, it has also happened because of bugs in the | |
2368 subroutine `alloca'. Verify that `alloca' works right, even | |
2369 for large blocks (many pages). | |
2370 | |
2371 *** test-distrib says that the distribution has been clobbered. | |
2372 *** or, temacs prints "Command key out of range 0-127". | |
2373 *** or, temacs runs and dumps emacs, but emacs totally fails to work. | |
2374 *** or, temacs gets errors dumping emacs. | |
2375 | |
2376 This can be because the .elc files have been garbled. Do not be | |
2377 fooled by the fact that most of a .elc file is text: these are | |
2378 binary files and can contain all 256 byte values. | |
2379 | |
2380 In particular `shar' cannot be used for transmitting GNU Emacs. | |
2381 It typically truncates "lines". What appear to be "lines" in | |
2382 a binary file can of course be of any length. Even once `shar' | |
2383 itself is made to work correctly, `sh' discards null characters | |
2384 when unpacking the shell archive. | |
2385 | |
2386 I have also seen character \177 changed into \377. I do not know | |
2387 what transfer means caused this problem. Various network | |
2388 file transfer programs are suspected of clobbering the high bit. | |
2389 | |
2390 If you have a copy of Emacs that has been damaged in its | |
2391 nonprinting characters, you can fix them: | |
2392 | |
2393 1) Record the names of all the .elc files. | |
2394 2) Delete all the .elc files. | |
2395 3) Recompile alloc.c with a value of PURESIZE twice as large. | |
2396 (See puresize.h.) You might as well save the old alloc.o. | |
2397 4) Remake emacs. It should work now. | |
2398 5) Running emacs, do Meta-x byte-compile-file repeatedly | |
2399 to recreate all the .elc files that used to exist. | |
2400 You may need to increase the value of the variable | |
2401 max-lisp-eval-depth to succeed in running the compiler interpreted | |
2402 on certain .el files. 400 was sufficient as of last report. | |
2403 6) Reinstall the old alloc.o (undoing changes to alloc.c if any) | |
2404 and remake temacs. | |
2405 7) Remake emacs. It should work now, with valid .elc files. | |
2406 | |
2407 *** temacs prints "Pure Lisp storage exhausted". | |
2408 | |
2409 This means that the Lisp code loaded from the .elc and .el | |
2410 files during temacs -l loadup inc dump took up more | |
2411 space than was allocated. | |
2412 | |
2413 This could be caused by | |
2414 1) adding code to the preloaded Lisp files | |
2415 2) adding more preloaded files in loadup.el | |
2416 3) having a site-init.el or site-load.el which loads files. | |
2417 Note that ANY site-init.el or site-load.el is nonstandard; | |
2418 if you have received Emacs from some other site | |
2419 and it contains a site-init.el or site-load.el file, consider | |
2420 deleting that file. | |
2421 4) getting the wrong .el or .elc files | |
2422 (not from the directory you expected). | |
2423 5) deleting some .elc files that are supposed to exist. | |
2424 This would cause the source files (.el files) to be | |
2425 loaded instead. They take up more room, so you lose. | |
2426 6) a bug in the Emacs distribution which underestimates | |
2427 the space required. | |
2428 | |
2429 If the need for more space is legitimate, change the definition | |
2430 of PURESIZE in puresize.h. | |
2431 | |
2432 But in some of the cases listed above, this problem is a consequence | |
2433 of something else that is wrong. Be sure to check and fix the real | |
2434 problem. | |
2435 | |
2436 *** Linux: Emacs crashes when dumping itself on Mac PPC running Yellow Dog GNU/Linux. | |
2437 | |
2438 The crashes happen inside the function Fmake_symbol; here's a typical | |
2439 C backtrace printed by GDB: | |
2440 | |
2441 0x190c0c0 in Fmake_symbol () | |
2442 (gdb) where | |
2443 #0 0x190c0c0 in Fmake_symbol () | |
2444 #1 0x1942ca4 in init_obarray () | |
2445 #2 0x18b3500 in main () | |
2446 #3 0x114371c in __libc_start_main (argc=5, argv=0x7ffff5b4, envp=0x7ffff5cc, | |
2447 | |
2448 This could happen because GCC version 2.95 and later changed the base | |
2449 of the load address to 0x10000000. Emacs needs to be told about this, | |
2450 but we currently cannot do that automatically, because that breaks | |
2451 other versions of GNU/Linux on the MacPPC. Until we find a way to | |
2452 distinguish between the Yellow Dog and the other varieties of | |
2453 GNU/Linux systems on the PPC, you will have to manually uncomment the | |
2454 following section near the end of the file src/m/macppc.h in the Emacs | |
2455 distribution: | |
2456 | |
2457 #if 0 /* This breaks things on PPC GNU/Linux except for Yellowdog, | |
2458 even with identical GCC, as, ld. Let's take it out until we | |
2459 know what's really going on here. */ | |
2460 /* GCC 2.95 and newer on GNU/Linux PPC changed the load address to | |
2461 0x10000000. */ | |
2462 #if defined __linux__ | |
2463 #if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95) | |
2464 #define DATA_SEG_BITS 0x10000000 | |
2465 #endif | |
2466 #endif | |
2467 #endif /* 0 */ | |
2468 | |
2469 Remove the "#if 0" and "#endif" directives which surround this, save | |
2470 the file, and then reconfigure and rebuild Emacs. The dumping process | |
2471 should now succeed. | |
2472 | |
2473 ** Installation | |
2474 | |
2475 *** Installing Emacs gets an error running `install-info'. | |
2476 | |
2477 You need to install a recent version of Texinfo; that package | |
2478 supplies the `install-info' command. | |
2479 | |
2480 ** First execution | |
2481 | |
2482 *** Emacs binary is not in executable format, and cannot be run. | |
2483 | |
2484 This was reported to happen when Emacs is built in a directory mounted | |
2485 via NFS, for some combinations of NFS client and NFS server. | |
2486 Usually, the file `emacs' produced in these cases is full of | |
2487 binary null characters, and the `file' utility says: | |
2488 | |
2489 emacs: ASCII text, with no line terminators | |
2490 | |
2491 We don't know what exactly causes this failure. A work-around is to | |
2492 build Emacs in a directory on a local disk. | |
2493 | |
2494 *** The dumped Emacs crashes when run, trying to write pure data. | |
2495 | |
2496 Two causes have been seen for such problems. | |
2497 | |
2498 1) On a system where getpagesize is not a system call, it is defined | |
2499 as a macro. If the definition (in both unexec.c and malloc.c) is wrong, | |
2500 it can cause problems like this. You might be able to find the correct | |
2501 value in the man page for a.out (5). | |
2502 | |
2503 2) Some systems allocate variables declared static among the | |
2504 initialized variables. Emacs makes all initialized variables in most | |
2505 of its files pure after dumping, but the variables declared static and | |
2506 not initialized are not supposed to be pure. On these systems you | |
2507 may need to add "#define static" to the m- or the s- file. | |
2508 | |
2509 * Emacs 19 problems | |
2510 | |
2511 ** Error messages `Wrong number of arguments: #<subr where-is-internal>, 5'. | |
2512 | |
2513 This typically results from having the powerkey library loaded. | |
2514 Powerkey was designed for Emacs 19.22. It is obsolete now because | |
2515 Emacs 19 now has this feature built in; and powerkey also calls | |
2516 where-is-internal in an obsolete way. | |
2517 | |
2518 So the fix is to arrange not to load powerkey. | |
2519 | |
2520 * Runtime problems on legacy systems | |
2521 | |
2522 This section covers bugs reported on very old hardware or software. | |
2523 If you are using hardware and an operating system shipped after 2000, | |
2524 it is unlikely you will see any of these. | |
2525 | |
2526 ** Ancient operating systems | |
2527 | |
2528 AIX 4.2 was end-of-lifed on Dec 31st, 1999. | |
2529 | |
2530 *** AIX: You get this compiler error message: | |
2531 | |
2532 Processing include file ./XMenuInt.h | |
2533 1501-106: (S) Include file X11/Xlib.h not found. | |
2534 | |
2535 This means your system was installed with only the X11 runtime i.d | |
2536 libraries. You have to find your sipo (bootable tape) and install | |
2537 X11Dev... with smit. | |
2538 | |
2539 (This report must be ancient. Bootable tapes are long dead.) | |
2540 | |
2541 *** AIX 3.2.4: Releasing Ctrl/Act key has no effect, if Shift is down. | |
2542 | |
2543 Due to a feature of AIX, pressing or releasing the Ctrl/Act key is | |
2544 ignored when the Shift, Alt or AltGr keys are held down. This can | |
2545 lead to the keyboard being "control-locked"--ordinary letters are | |
2546 treated as control characters. | |
2547 | |
2548 You can get out of this "control-locked" state by pressing and | |
2549 releasing Ctrl/Act while not pressing or holding any other keys. | |
2550 | |
2551 *** AIX 3.2.5: You get this message when running Emacs: | |
2552 | |
2553 Could not load program emacs | |
2554 Symbol smtcheckinit in csh is undefined | |
2555 Error was: Exec format error | |
2556 | |
2557 or this one: | |
2558 | |
2559 Could not load program .emacs | |
2560 Symbol _system_con in csh is undefined | |
2561 Symbol _fp_trapsta in csh is undefined | |
2562 Error was: Exec format error | |
2563 | |
2564 These can happen when you try to run on AIX 3.2.5 a program that was | |
2565 compiled with 3.2.4. The fix is to recompile. | |
2566 | |
2567 *** AIX 4.2: Emacs gets a segmentation fault at startup. | |
2568 | |
2569 If you are using IBM's xlc compiler, compile emacs.c | |
2570 without optimization; that should avoid the problem. | |
2571 | |
2572 *** ISC Unix | |
2573 | |
2574 **** ISC: display-time causes kernel problems on ISC systems. | |
2575 | |
2576 Under Interactive Unix versions 3.0.1 and 4.0 (and probably other | |
2577 versions), display-time causes the loss of large numbers of STREVENT | |
2578 cells. Eventually the kernel's supply of these cells is exhausted. | |
2579 This makes emacs and the whole system run slow, and can make other | |
2580 processes die, in particular pcnfsd. | |
2581 | |
2582 Other emacs functions that communicate with remote processes may have | |
2583 the same problem. Display-time seems to be far the worst. | |
2584 | |
2585 The only known fix: Don't run display-time. | |
2586 | |
2587 *** SunOS | |
2588 | |
2589 SunOS 4.1.4 stopped shipping on Sep 30 1998. | |
2590 | |
2591 **** SunOS: You get linker errors | |
2592 ld: Undefined symbol | |
2593 _get_wmShellWidgetClass | |
2594 _get_applicationShellWidgetClass | |
2595 | |
2596 **** Sun 4.0.x: M-x shell persistently reports "Process shell exited abnormally with code 1". | |
2597 | |
2598 This happened on Suns as a result of what is said to be a bug in Sunos | |
2599 version 4.0.x. The only fix was to reboot the machine. | |
2600 | |
2601 **** SunOS4.1.1 and SunOS4.1.3: Mail is lost when sent to local aliases. | |
2602 | |
2603 Many emacs mail user agents (VM and rmail, for instance) use the | |
2604 sendmail.el library. This library can arrange for mail to be | |
2605 delivered by passing messages to the /usr/lib/sendmail (usually) | |
2606 program . In doing so, it passes the '-t' flag to sendmail, which | |
2607 means that the name of the recipient of the message is not on the | |
2608 command line and, therefore, that sendmail must parse the message to | |
2609 obtain the destination address. | |
2610 | |
2611 There is a bug in the SunOS4.1.1 and SunOS4.1.3 versions of sendmail. | |
2612 In short, when given the -t flag, the SunOS sendmail won't recognize | |
2613 non-local (i.e. NIS) aliases. It has been reported that the Solaris | |
2614 2.x versions of sendmail do not have this bug. For those using SunOS | |
2615 4.1, the best fix is to install sendmail V8 or IDA sendmail (which | |
2616 have other advantages over the regular sendmail as well). At the time | |
2617 of this writing, these official versions are available: | |
2618 | |
2619 Sendmail V8 on ftp.cs.berkeley.edu in /ucb/sendmail: | |
2620 sendmail.8.6.9.base.tar.Z (the base system source & documentation) | |
2621 sendmail.8.6.9.cf.tar.Z (configuration files) | |
2622 sendmail.8.6.9.misc.tar.Z (miscellaneous support programs) | |
2623 sendmail.8.6.9.xdoc.tar.Z (extended documentation, with postscript) | |
2624 | |
2625 IDA sendmail on vixen.cso.uiuc.edu in /pub: | |
2626 sendmail-5.67b+IDA-1.5.tar.gz | |
2627 | |
2628 **** Sunos 4: You get the error ld: Undefined symbol __lib_version. | |
2629 | |
2630 This is the result of using cc or gcc with the shared library meant | |
2631 for acc (the Sunpro compiler). Check your LD_LIBRARY_PATH and delete | |
2632 /usr/lang/SC2.0.1 or some similar directory. | |
2633 | |
2634 **** SunOS 4.1.3: Emacs unpredictably crashes in _yp_dobind_soft. | |
2635 | |
2636 This happens if you configure Emacs specifying just `sparc-sun-sunos4' | |
2637 on a system that is version 4.1.3. You must specify the precise | |
2638 version number (or let configure figure out the configuration, which | |
2639 it can do perfectly well for SunOS). | |
2640 | |
2641 **** Sunos 4.1.3: Emacs gets hung shortly after startup. | |
2642 | |
2643 We think this is due to a bug in Sunos. The word is that | |
2644 one of these Sunos patches fixes the bug: | |
2645 | |
2646 100075-11 100224-06 100347-03 100482-05 100557-02 100623-03 100804-03 101080-01 | |
2647 100103-12 100249-09 100496-02 100564-07 100630-02 100891-10 101134-01 | |
2648 100170-09 100296-04 100377-09 100507-04 100567-04 100650-02 101070-01 101145-01 | |
2649 100173-10 100305-15 100383-06 100513-04 100570-05 100689-01 101071-03 101200-02 | |
2650 100178-09 100338-05 100421-03 100536-02 100584-05 100784-01 101072-01 101207-01 | |
2651 | |
2652 We don't know which of these patches really matter. If you find out | |
2653 which ones, please inform bug-gnu-emacs@gnu.org. | |
2654 | |
2655 **** SunOS 4: Emacs processes keep going after you kill the X server | |
2656 (or log out, if you logged in using X). | |
2657 | |
2658 Someone reported that recompiling with GCC 2.7.0 fixed this problem. | |
2659 | |
2660 The fix to this is to install patch 100573 for OpenWindows 3.0 | |
2661 or link libXmu statically. | |
2662 | |
2663 **** Sunos 5.3: Subprocesses remain, hanging but not zombies. | |
2664 | |
2665 A bug in Sunos 5.3 causes Emacs subprocesses to remain after Emacs | |
2666 exits. Sun patch # 101415-02 is part of the fix for this, but it only | |
2667 applies to ptys, and doesn't fix the problem with subprocesses | |
2668 communicating through pipes. | |
2669 | |
2670 *** Apollo Domain | |
2671 | |
2672 **** Shell mode ignores interrupts on Apollo Domain. | |
2673 | |
2674 You may find that M-x shell prints the following message: | |
2675 | |
2676 Warning: no access to tty; thus no job control in this shell... | |
2677 | |
2678 This can happen if there are not enough ptys on your system. | |
2679 Here is how to make more of them. | |
2680 | |
2681 % cd /dev | |
2682 % ls pty* | |
2683 # shows how many pty's you have. I had 8, named pty0 to pty7) | |
2684 % /etc/crpty 8 | |
2685 # creates eight new pty's | |
2686 | |
2687 *** Irix | |
2688 | |
2689 *** Irix 6.2: No visible display on mips-sgi-irix6.2 when compiling with GCC 2.8.1. | |
2690 | |
2691 This problem went away after installing the latest IRIX patches | |
2692 as of 8 Dec 1998. | |
2693 | |
2694 The same problem has been reported on Irix 6.3. | |
2695 | |
2696 *** Irix 6.3: substituting environment variables in file names | |
2697 in the minibuffer gives peculiar error messages such as | |
2698 | |
2699 Substituting nonexistent environment variable "" | |
2700 | |
2701 This is not an Emacs bug; it is caused by something in SGI patch | |
2702 003082 August 11, 1998. | |
2703 | |
2704 *** OPENSTEP | |
2705 | |
2706 **** OPENSTEP 4.2: Compiling syntax.c with gcc 2.7.2.1 fails. | |
2707 | |
2708 The compiler was reported to crash while compiling syntax.c with the | |
2709 following message: | |
2710 | |
2711 cc: Internal compiler error: program cc1obj got fatal signal 11 | |
2712 | |
2713 To work around this, replace the macros UPDATE_SYNTAX_TABLE_FORWARD, | |
2714 INC_BOTH, and INC_FROM with functions. To this end, first define 3 | |
2715 functions, one each for every macro. Here's an example: | |
2716 | |
2717 static int update_syntax_table_forward(int from) | |
2718 { | |
2719 return(UPDATE_SYNTAX_TABLE_FORWARD(from)); | |
2720 }/*update_syntax_table_forward*/ | |
2721 | |
2722 Then replace all references to UPDATE_SYNTAX_TABLE_FORWARD in syntax.c | |
2723 with a call to the function update_syntax_table_forward. | |
2724 | |
2725 *** Solaris 2.x | |
2726 | |
2727 **** Strange results from format %d in a few cases, on a Sun. | |
2728 | |
2729 Sun compiler version SC3.0 has been found to miscompile part of | |
2730 editfns.c. The workaround is to compile with some other compiler such | |
2731 as GCC. | |
2732 | |
2733 **** On Solaris, Emacs dumps core if lisp-complete-symbol is called. | |
2734 | |
2735 If you compile Emacs with the -fast or -xO4 option with version 3.0.2 | |
2736 of the Sun C compiler, Emacs dumps core when lisp-complete-symbol is | |
2737 called. The problem does not happen if you compile with GCC. | |
2738 | |
2739 **** On Solaris, Emacs crashes if you use (display-time). | |
2740 | |
2741 This can happen if you configure Emacs without specifying the precise | |
2742 version of Solaris that you are using. | |
2743 | |
2744 **** Solaris 2.3 and 2.4: Unpredictable segmentation faults. | |
2745 | |
2746 A user reported that this happened in 19.29 when it was compiled with | |
2747 the Sun compiler, but not when he recompiled with GCC 2.7.0. | |
2748 | |
2749 We do not know whether something in Emacs is partly to blame for this. | |
2750 | |
2751 **** Solaris 2.4: Emacs dumps core on startup. | |
2752 | |
2753 Bill Sebok says that the cause of this is Solaris 2.4 vendor patch | |
2754 102303-05, which extends the Solaris linker to deal with the Solaris | |
2755 Common Desktop Environment's linking needs. You can fix the problem | |
2756 by removing this patch and installing patch 102049-02 instead. | |
2757 However, that linker version won't work with CDE. | |
2758 | |
2759 Solaris 2.5 comes with a linker that has this bug. It is reported that if | |
2760 you install all the latest patches (as of June 1996), the bug is fixed. | |
2761 We suspect the crucial patch is one of these, but we don't know | |
2762 for certain. | |
2763 | |
2764 103093-03: [README] SunOS 5.5: kernel patch (2140557 bytes) | |
2765 102832-01: [README] OpenWindows 3.5: Xview Jumbo Patch (4181613 bytes) | |
2766 103242-04: [README] SunOS 5.5: linker patch (595363 bytes) | |
2767 | |
2768 (One user reports that the bug was fixed by those patches together | |
2769 with patches 102980-04, 103279-01, 103300-02, and 103468-01.) | |
2770 | |
2771 If you can determine which patch does fix the bug, please tell | |
2772 bug-gnu-emacs@gnu.org. | |
2773 | |
2774 Meanwhile, the GNU linker links Emacs properly on both Solaris 2.4 and | |
2775 Solaris 2.5. | |
2776 | |
2777 **** Solaris 2.4: Dired hangs and C-g does not work. Or Emacs hangs | |
2778 forever waiting for termination of a subprocess that is a zombie. | |
2779 | |
2780 casper@fwi.uva.nl says the problem is in X11R6. Rebuild libX11.so | |
2781 after changing the file xc/config/cf/sunLib.tmpl. Change the lines | |
2782 | |
2783 #if ThreadedX | |
2784 #define SharedX11Reqs -lthread | |
2785 #endif | |
2786 | |
2787 to: | |
2788 | |
2789 #if OSMinorVersion < 4 | |
2790 #if ThreadedX | |
2791 #define SharedX11Reqs -lthread | |
2792 #endif | |
2793 #endif | |
2794 | |
2795 Be sure also to edit x/config/cf/sun.cf so that OSMinorVersion is 4 | |
2796 (as it should be for Solaris 2.4). The file has three definitions for | |
2797 OSMinorVersion: the first is for x86, the second for SPARC under | |
2798 Solaris, and the third for SunOS 4. Make sure to update the | |
2799 definition for your type of machine and system. | |
2800 | |
2801 Then do `make Everything' in the top directory of X11R6, to rebuild | |
2802 the makefiles and rebuild X. The X built this way work only on | |
2803 Solaris 2.4, not on 2.3. | |
2804 | |
2805 For multithreaded X to work it is necessary to install patch | |
2806 101925-02 to fix problems in header files [2.4]. You need | |
2807 to reinstall gcc or re-run just-fixinc after installing that | |
2808 patch. | |
2809 | |
2810 However, Frank Rust <frust@iti.cs.tu-bs.de> used a simpler solution: | |
2811 he changed | |
2812 #define ThreadedX YES | |
2813 to | |
2814 #define ThreadedX NO | |
2815 in sun.cf and did `make World' to rebuild X11R6. Removing all | |
2816 `-DXTHREAD*' flags and `-lthread' entries from lib/X11/Makefile and | |
2817 typing 'make install' in that directory also seemed to work. | |
2818 | |
2819 **** Solaris 2.x: GCC complains "64 bit integer types not supported". | |
2820 | |
2821 This suggests that GCC is not installed correctly. Most likely you | |
2822 are using GCC 2.7.2.3 (or earlier) on Solaris 2.6 (or later); this | |
2823 does not work without patching. To run GCC 2.7.2.3 on Solaris 2.6 or | |
2824 later, you must patch fixinc.svr4 and reinstall GCC from scratch as | |
2825 described in the Solaris FAQ | |
2826 <http://www.wins.uva.nl/pub/solaris/solaris2.html>. A better fix is | |
2827 to upgrade to GCC 2.8.1 or later. | |
2828 | |
2829 **** Solaris 2.7: Building Emacs with WorkShop Compilers 5.0 98/12/15 | |
2830 C 5.0 failed, apparently with non-default CFLAGS, most probably due to | |
2831 compiler bugs. Using Sun Solaris 2.7 Sun WorkShop 6 update 1 C | |
2832 release was reported to work without problems. It worked OK on | |
2833 another system with Solaris 8 using apparently the same 5.0 compiler | |
2834 and the default CFLAGS. | |
2835 | |
2836 **** Solaris 2.x: Emacs dumps core when built with Motif. | |
2837 | |
2838 The Solaris Motif libraries are buggy, at least up through Solaris 2.5.1. | |
2839 Install the current Motif runtime library patch appropriate for your host. | |
2840 (Make sure the patch is current; some older patch versions still have the bug.) | |
2841 You should install the other patches recommended by Sun for your host, too. | |
2842 You can obtain Sun patches from ftp://sunsolve.sun.com/pub/patches/; | |
2843 look for files with names ending in `.PatchReport' to see which patches | |
2844 are currently recommended for your host. | |
2845 | |
2846 On Solaris 2.6, Emacs is said to work with Motif when Solaris patch | |
2847 105284-12 is installed, but fail when 105284-15 is installed. | |
2848 105284-18 might fix it again. | |
2849 | |
2850 **** Solaris 2.6 and 7: the Compose key does not work. | |
2851 | |
2852 This is a bug in Motif in Solaris. Supposedly it has been fixed for | |
2853 the next major release of Solaris. However, if someone with Sun | |
2854 support complains to Sun about the bug, they may release a patch. | |
2855 If you do this, mention Sun bug #4188711. | |
2856 | |
2857 One workaround is to use a locale that allows non-ASCII characters. | |
2858 For example, before invoking emacs, set the LC_ALL environment | |
2859 variable to "en_US" (American English). The directory /usr/lib/locale | |
2860 lists the supported locales; any locale other than "C" or "POSIX" | |
2861 should do. | |
2862 | |
2863 pen@lysator.liu.se says (Feb 1998) that the Compose key does work | |
2864 if you link with the MIT X11 libraries instead of the Solaris X11 | |
2865 libraries. | |
2866 | |
2867 *** HP/UX versions before 11.0 | |
2868 | |
2869 HP/UX 9 was end-of-lifed in December 1998. | |
2870 HP/UX 10 was end-of-lifed in May 1999. | |
2871 | |
2872 **** HP/UX 9: Emacs crashes with SIGBUS or SIGSEGV after you delete a frame. | |
2873 | |
2874 We think this is due to a bug in the X libraries provided by HP. With | |
2875 the alternative X libraries in /usr/contrib/mitX11R5/lib, the problem | |
2876 does not happen. | |
2877 | |
2878 *** HP/UX 10: Large file support is disabled. | |
2879 | |
2880 See the comments in src/s/hpux10.h. | |
2881 | |
2882 *** HP/UX: Emacs is slow using X11R5. | |
2883 | |
2884 This happens if you use the MIT versions of the X libraries--it | |
2885 doesn't run as fast as HP's version. People sometimes use the version | |
2886 because they see the HP version doesn't have the libraries libXaw.a, | |
2887 libXmu.a, libXext.a and others. HP/UX normally doesn't come with | |
2888 those libraries installed. To get good performance, you need to | |
2889 install them and rebuild Emacs. | |
2890 | |
2891 *** Ultrix and Digital Unix | |
2892 | |
2893 **** Ultrix 4.2: `make install' fails on install-doc with `Error 141'. | |
2894 | |
2895 This happens on Ultrix 4.2 due to failure of a pipeline of tar | |
2896 commands. We don't know why they fail, but the bug seems not to be in | |
2897 Emacs. The workaround is to run the shell command in install-doc by | |
2898 hand. | |
2899 | |
2900 **** Digital Unix 4.0: Garbled display on non-X terminals when Emacs runs. | |
2901 | |
2902 So far it appears that running `tset' triggers this problem (when TERM | |
2903 is vt100, at least). If you do not run `tset', then Emacs displays | |
2904 properly. If someone can tell us precisely which effect of running | |
2905 `tset' actually causes the problem, we may be able to implement a fix | |
2906 in Emacs. | |
2907 | |
2908 **** Ultrix: `expand-file-name' fails to work on any but the machine you dumped Emacs on. | |
2909 | |
2910 On Ultrix, if you use any of the functions which look up information | |
2911 in the passwd database before dumping Emacs (say, by using | |
2912 expand-file-name in site-init.el), then those functions will not work | |
2913 in the dumped Emacs on any host but the one Emacs was dumped on. | |
2914 | |
2915 The solution? Don't use expand-file-name in site-init.el, or in | |
2916 anything it loads. Yuck - some solution. | |
2917 | |
2918 I'm not sure why this happens; if you can find out exactly what is | |
2919 going on, and perhaps find a fix or a workaround, please let us know. | |
2920 Perhaps the YP functions cache some information, the cache is included | |
2921 in the dumped Emacs, and is then inaccurate on any other host. | |
2922 | |
2923 *** SVr4 | |
2924 | |
2925 **** SVr4: On some variants of SVR4, Emacs does not work at all with X. | |
2926 | |
2927 Try defining BROKEN_FIONREAD in your config.h file. If this solves | |
2928 the problem, please send a bug report to tell us this is needed; be | |
2929 sure to say exactly what type of machine and system you are using. | |
2930 | |
2931 **** SVr4: After running emacs once, subsequent invocations crash. | |
2932 | |
2933 Some versions of SVR4 have a serious bug in the implementation of the | |
2934 mmap () system call in the kernel; this causes emacs to run correctly | |
2935 the first time, and then crash when run a second time. | |
2936 | |
2937 Contact your vendor and ask for the mmap bug fix; in the mean time, | |
2938 you may be able to work around the problem by adding a line to your | |
2939 operating system description file (whose name is reported by the | |
2940 configure script) that reads: | |
2941 #define SYSTEM_MALLOC | |
2942 This makes Emacs use memory less efficiently, but seems to work around | |
2943 the kernel bug. | |
2944 | |
2945 *** Irix 5 and earlier | |
2946 | |
2947 Exactly when Irix-5 end-of-lifed is obscure. But since Irix 6.0 | |
2948 shipped in 1994, it has been some years. | |
2949 | |
2950 **** Irix 5.2: unexelfsgi.c can't find cmplrs/stsupport.h. | |
2951 | |
2952 The file cmplrs/stsupport.h was included in the wrong file set in the | |
2953 Irix 5.2 distribution. You can find it in the optional fileset | |
2954 compiler_dev, or copy it from some other Irix 5.2 system. A kludgy | |
2955 workaround is to change unexelfsgi.c to include sym.h instead of | |
2956 syms.h. | |
2957 | |
2958 **** Irix 5.3: "out of virtual swap space". | |
2959 | |
2960 This message occurs when the system runs out of swap space due to too | |
2961 many large programs running. The solution is either to provide more | |
2962 swap space or to reduce the number of large programs being run. You | |
2963 can check the current status of the swap space by executing the | |
2964 command `swap -l'. | |
2965 | |
2966 You can increase swap space by changing the file /etc/fstab. Adding a | |
2967 line like this: | |
2968 | |
2969 /usr/swap/swap.more swap swap pri=3 0 0 | |
2970 | |
2971 where /usr/swap/swap.more is a file previously created (for instance | |
2972 by using /etc/mkfile), will increase the swap space by the size of | |
2973 that file. Execute `swap -m' or reboot the machine to activate the | |
2974 new swap area. See the manpages for `swap' and `fstab' for further | |
2975 information. | |
2976 | |
2977 The objectserver daemon can use up lots of memory because it can be | |
2978 swamped with NIS information. It collects information about all users | |
2979 on the network that can log on to the host. | |
2980 | |
2981 If you want to disable the objectserver completely, you can execute | |
2982 the command `chkconfig objectserver off' and reboot. That may disable | |
2983 some of the window system functionality, such as responding CDROM | |
2984 icons. | |
2985 | |
2986 You can also remove NIS support from the objectserver. The SGI `admin' | |
2987 FAQ has a detailed description on how to do that; see question 35 | |
2988 ("Why isn't the objectserver working?"). The admin FAQ can be found at | |
2989 ftp://viz.tamu.edu/pub/sgi/faq/. | |
2990 | |
2991 **** Irix 5.3: Emacs crashes in utmpname. | |
2992 | |
2993 This problem is fixed in Patch 3175 for Irix 5.3. | |
2994 It is also fixed in Irix versions 6.2 and up. | |
2995 | |
2996 **** Irix 6.0: Make tries (and fails) to build a program named unexelfsgi. | |
2997 | |
2998 A compiler bug inserts spaces into the string "unexelfsgi . o" | |
2999 in src/Makefile. Edit src/Makefile, after configure is run, | |
3000 find that string, and take out the spaces. | |
3001 | |
3002 Compiler fixes in Irix 6.0.1 should eliminate this problem. | |
3003 | |
3004 *** SCO Unix and UnixWare | |
3005 | |
3006 **** SCO 3.2v4: Unusable default font. | |
3007 | |
3008 The Open Desktop environment comes with default X resource settings | |
3009 that tell Emacs to use a variable-width font. Emacs cannot use such | |
3010 fonts, so it does not work. | |
3011 | |
3012 This is caused by the file /usr/lib/X11/app-defaults/ScoTerm, which is | |
3013 the application-specific resource file for the `scoterm' terminal | |
3014 emulator program. It contains several extremely general X resources | |
3015 that affect other programs besides `scoterm'. In particular, these | |
3016 resources affect Emacs also: | |
3017 | |
3018 *Font: -*-helvetica-medium-r-*--12-*-p-* | |
3019 *Background: scoBackground | |
3020 *Foreground: scoForeground | |
3021 | |
3022 The best solution is to create an application-specific resource file for | |
3023 Emacs, /usr/lib/X11/sco/startup/Emacs, with the following contents: | |
3024 | |
3025 Emacs*Font: -*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1 | |
3026 Emacs*Background: white | |
3027 Emacs*Foreground: black | |
3028 | |
3029 (These settings mimic the Emacs defaults, but you can change them to | |
3030 suit your needs.) This resource file is only read when the X server | |
3031 starts up, so you should restart it by logging out of the Open Desktop | |
3032 environment or by running `scologin stop; scologin start` from the shell | |
3033 as root. Alternatively, you can put these settings in the | |
3034 /usr/lib/X11/app-defaults/Emacs resource file and simply restart Emacs, | |
3035 but then they will not affect remote invocations of Emacs that use the | |
3036 Open Desktop display. | |
3037 | |
3038 These resource files are not normally shared across a network of SCO | |
3039 machines; you must create the file on each machine individually. | |
3040 | |
3041 **** SCO 4.2.0: Regular expressions matching bugs on SCO systems. | |
3042 | |
3043 On SCO, there are problems in regexp matching when Emacs is compiled | |
3044 with the system compiler. The compiler version is "Microsoft C | |
3045 version 6", SCO 4.2.0h Dev Sys Maintenance Supplement 01/06/93; Quick | |
3046 C Compiler Version 1.00.46 (Beta). The solution is to compile with | |
3047 GCC. | |
3048 | |
3049 **** UnixWare 2.1: Error 12 (virtual memory exceeded) when dumping Emacs. | |
3050 | |
3051 Paul Abrahams (abrahams@acm.org) reports that with the installed | |
3052 virtual memory settings for UnixWare 2.1.2, an Error 12 occurs during | |
3053 the "make" that builds Emacs, when running temacs to dump emacs. That | |
3054 error indicates that the per-process virtual memory limit has been | |
3055 exceeded. The default limit is probably 32MB. Raising the virtual | |
3056 memory limit to 40MB should make it possible to finish building Emacs. | |
3057 | |
3058 You can do this with the command `ulimit' (sh) or `limit' (csh). | |
3059 But you have to be root to do it. | |
3060 | |
3061 According to Martin Sohnius, you can also retune this in the kernel: | |
3062 | |
3063 # /etc/conf/bin/idtune SDATLIM 33554432 ## soft data size limit | |
3064 # /etc/conf/bin/idtune HDATLIM 33554432 ## hard " | |
3065 # /etc/conf/bin/idtune SVMMSIZE unlimited ## soft process size limit | |
3066 # /etc/conf/bin/idtune HVMMSIZE unlimited ## hard " | |
3067 # /etc/conf/bin/idbuild -B | |
3068 | |
3069 (He recommends you not change the stack limit, though.) | |
3070 These changes take effect when you reboot. | |
3071 | |
3072 *** Linux 1.x | |
3073 | |
3074 **** Linux 1.0-1.04: Typing C-c C-c in Shell mode kills your X server. | |
3075 | |
3076 This happens with Linux kernel 1.0 thru 1.04, approximately. The workaround is | |
3077 to define SIGNALS_VIA_CHARACTERS in config.h and recompile Emacs. | |
3078 Newer Linux kernel versions don't have this problem. | |
3079 | |
3080 **** Linux 1.3: Output from subprocess (such as man or diff) is randomly | |
3081 truncated on GNU/Linux systems. | |
3082 | |
3083 This is due to a kernel bug which seems to be fixed in Linux version | |
3084 1.3.75. | |
3085 | |
3086 ** Windows 3.1, 95, 98, and ME | |
3087 | |
3088 *** MS-Windows NT/95: Problems running Perl under Emacs | |
2161 | 3089 |
2162 `perl -de 0' just hangs when executed in an Emacs subshell. | 3090 `perl -de 0' just hangs when executed in an Emacs subshell. |
2163 The fault lies with Perl (indirectly with Windows NT/95). | 3091 The fault lies with Perl (indirectly with Windows NT/95). |
2164 | 3092 |
2165 The problem is that the Perl debugger explicitly opens a connection to | 3093 The problem is that the Perl debugger explicitly opens a connection to |
2218 ! $console = ""; | 3146 ! $console = ""; |
2219 $rcfile="perldb.ini"; | 3147 $rcfile="perldb.ini"; |
2220 } | 3148 } |
2221 else { | 3149 else { |
2222 | 3150 |
2223 ** On MS-Windows 95, Alt-f6 does not get through to Emacs. | 3151 *** MS-Windows 95: Alt-f6 does not get through to Emacs. |
2224 | 3152 |
2225 This character seems to be trapped by the kernel in Windows 95. | 3153 This character seems to be trapped by the kernel in Windows 95. |
2226 You can enter M-f6 by typing ESC f6. | 3154 You can enter M-f6 by typing ESC f6. |
2227 | 3155 |
2228 ** Typing Alt-Shift has strange effects on MS-Windows. | 3156 *** MS-Windows 95/98/ME: subprocesses do not terminate properly. |
2229 | |
2230 This combination of keys is a command to change keyboard layout. If | |
2231 you proceed to type another non-modifier key before you let go of Alt | |
2232 and Shift, the Alt and Shift act as modifiers in the usual way. A | |
2233 more permanent work around is to change it to another key combination, | |
2234 or disable it in the keyboard control panel. | |
2235 | |
2236 ** Interrupting Cygwin port of Bash from Emacs doesn't work. | |
2237 | |
2238 Cygwin 1.x builds of the ported Bash cannot be interrupted from the | |
2239 MS-Windows version of Emacs. This is due to some change in the Bash | |
2240 port or in the Cygwin library which apparently make Bash ignore the | |
2241 keyboard interrupt event sent by Emacs to Bash. (Older Cygwin ports | |
2242 of Bash, up to b20.1, did receive SIGINT from Emacs.) | |
2243 | |
2244 ** Accessing remote files with ange-ftp hangs the MS-Windows version of Emacs. | |
2245 | |
2246 If the FTP client is the Cygwin port of GNU `ftp', this appears to be | |
2247 due to some bug in the Cygwin DLL or some incompatibility between it | |
2248 and the implementation of asynchronous subprocesses in the Windows | |
2249 port of Emacs. Specifically, some parts of the FTP server responses | |
2250 are not flushed out, apparently due to buffering issues, which | |
2251 confuses ange-ftp. | |
2252 | |
2253 The solution is to downgrade to an older version of the Cygwin DLL | |
2254 (version 1.3.2 was reported to solve the problem), or use the stock | |
2255 Windows FTP client, usually found in the `C:\WINDOWS' or 'C:\WINNT' | |
2256 directory. To force ange-ftp use the stock Windows client, set the | |
2257 variable `ange-ftp-ftp-program-name' to the absolute file name of the | |
2258 client's executable. For example: | |
2259 | |
2260 (setq ange-ftp-ftp-program-name "c:/windows/ftp.exe") | |
2261 | |
2262 If you want to stick with the Cygwin FTP client, you can work around | |
2263 this problem by putting this in your `.emacs' file: | |
2264 | |
2265 (setq ange-ftp-ftp-program-args '("-i" "-n" "-g" "-v" "--prompt" "") | |
2266 | |
2267 ** lpr commands don't work on MS-Windows with some cheap printers. | |
2268 | |
2269 This problem may also strike other platforms, but the solution is | |
2270 likely to be a global one, and not Emacs specific. | |
2271 | |
2272 Many cheap inkjet, and even some cheap laser printers, do not | |
2273 print plain text anymore, they will only print through graphical | |
2274 printer drivers. A workaround on MS-Windows is to use Windows' basic | |
2275 built in editor to print (this is possibly the only useful purpose it | |
2276 has): | |
2277 | |
2278 (setq printer-name "") ;; notepad takes the default | |
2279 (setq lpr-command "notepad") ;; notepad | |
2280 (setq lpr-switches nil) ;; not needed | |
2281 (setq lpr-printer-switch "/P") ;; run notepad as batch printer | |
2282 | |
2283 ** Antivirus software interacts badly with the MS-Windows version of Emacs. | |
2284 | |
2285 The usual manifestation of these problems is that subprocesses don't | |
2286 work or even wedge the entire system. In particular, "M-x shell RET" | |
2287 was reported to fail to work. But other commands also sometimes don't | |
2288 work when an antivirus package is installed. | |
2289 | |
2290 The solution is to switch the antivirus software to a less aggressive | |
2291 mode (e.g., disable the ``auto-protect'' feature), or even uninstall | |
2292 or disable it entirely. | |
2293 | |
2294 ** On MS-Windows 95/98/ME, subprocesses do not terminate properly. | |
2295 | 3157 |
2296 This is a limitation of the Operating System, and can cause problems | 3158 This is a limitation of the Operating System, and can cause problems |
2297 when shutting down Windows. Ensure that all subprocesses are exited | 3159 when shutting down Windows. Ensure that all subprocesses are exited |
2298 cleanly before exiting Emacs. For more details, see the FAQ at | 3160 cleanly before exiting Emacs. For more details, see the FAQ at |
2299 http://www.gnu.org/software/emacs/windows/. | 3161 http://www.gnu.org/software/emacs/windows/. |
2300 | 3162 |
2301 ** MS-Windows 95/98/ME crashes when Emacs invokes non-existent programs. | 3163 *** MS-Windows 95/98/ME: crashes when Emacs invokes non-existent programs. |
2302 | 3164 |
2303 When a program you are trying to run is not found on the PATH, | 3165 When a program you are trying to run is not found on the PATH, |
2304 Windows might respond by crashing or locking up your system. In | 3166 Windows might respond by crashing or locking up your system. In |
2305 particular, this has been reported when trying to compile a Java | 3167 particular, this has been reported when trying to compile a Java |
2306 program in JDEE when javac.exe is installed, but not on the system | 3168 program in JDEE when javac.exe is installed, but not on the system |
2307 PATH. | 3169 PATH. |
2308 | |
2309 ** Pressing the mouse button on MS-Windows does not give a mouse-2 event. | |
2310 | |
2311 This is usually a problem with the mouse driver. Because most Windows | |
2312 programs do not do anything useful with the middle mouse button, many | |
2313 mouse drivers allow you to define the wheel press to do something | |
2314 different. Some drivers do not even have the option to generate a | |
2315 middle button press. In such cases, setting the wheel press to | |
2316 "scroll" sometimes works if you press the button twice. Trying a | |
2317 generic mouse driver might help. | |
2318 | |
2319 ** Scrolling the mouse wheel on MS-Windows always scrolls the top window. | |
2320 | |
2321 This is another common problem with mouse drivers. Instead of | |
2322 generating scroll events, some mouse drivers try to fake scroll bar | |
2323 movement. But they are not intelligent enough to handle multiple | |
2324 scroll bars within a frame. Trying a generic mouse driver might help. | |
2325 | |
2326 ** Mail sent through Microsoft Exchange in some encodings appears to be | |
2327 mangled and is not seen correctly in Rmail or Gnus. We don't know | |
2328 exactly what happens, but it isn't an Emacs problem in cases we've | |
2329 seen. | |
2330 | |
2331 ** On MS-Windows, you cannot use the right-hand ALT key and the left-hand | |
2332 CTRL key together to type a Control-Meta character. | |
2333 | |
2334 This is a consequence of a misfeature beyond Emacs's control. | |
2335 | |
2336 Under Windows, the AltGr key on international keyboards generates key | |
2337 events with the modifiers Right-Alt and Left-Ctrl. Since Emacs cannot | |
2338 distinguish AltGr from an explicit Right-Alt and Left-Ctrl | |
2339 combination, whenever it sees Right-Alt and Left-Ctrl it assumes that | |
2340 AltGr has been pressed. The variable `w32-recognize-altgr' can be set | |
2341 to nil to tell Emacs that AltGr is really Ctrl and Alt. | |
2342 | |
2343 ** Under some X-servers running on MS-Windows, Emacs' display is incorrect. | |
2344 | |
2345 The symptoms are that Emacs does not completely erase blank areas of the | |
2346 screen during scrolling or some other screen operations (e.g., selective | |
2347 display or when killing a region). M-x recenter will cause the screen | |
2348 to be completely redisplayed and the "extra" characters will disappear. | |
2349 | |
2350 This is known to occur under Exceed 6, and possibly earlier versions | |
2351 as well; it is reportedly solved in version 6.2.0.16 and later. The | |
2352 problem lies in the X-server settings. | |
2353 | |
2354 There are reports that you can solve the problem with Exceed by | |
2355 running `Xconfig' from within NT, choosing "X selection", then | |
2356 un-checking the boxes "auto-copy X selection" and "auto-paste to X | |
2357 selection". | |
2358 | |
2359 Of this does not work, please inform bug-gnu-emacs@gnu.org. Then | |
2360 please call support for your X-server and see if you can get a fix. | |
2361 If you do, please send it to bug-gnu-emacs@gnu.org so we can list it | |
2362 here. | |
2363 | |
2364 * Build-time problems | |
2365 | |
2366 ** Configuration | |
2367 | |
2368 *** The `configure' script doesn't find the jpeg library. | |
2369 | |
2370 There are reports that this happens on some systems because the linker | |
2371 by default only looks for shared libraries, but jpeg distribution by | |
2372 default only installs a nonshared version of the library, `libjpeg.a'. | |
2373 | |
2374 If this is the problem, you can configure the jpeg library with the | |
2375 `--enable-shared' option and then rebuild libjpeg. This produces a | |
2376 shared version of libjpeg, which you need to install. Finally, rerun | |
2377 the Emacs configure script, which should now find the jpeg library. | |
2378 Alternatively, modify the generated src/Makefile to link the .a file | |
2379 explicitly, and edit src/config.h to define HAVE_JPEG. | |
2380 | |
2381 *** AIX: You get this compiler error message: | |
2382 | |
2383 Processing include file ./XMenuInt.h | |
2384 1501-106: (S) Include file X11/Xlib.h not found. | |
2385 | |
2386 This means your system was installed with only the X11 runtime i.d | |
2387 libraries. You have to find your sipo (bootable tape) and install | |
2388 X11Dev... with smit. | |
2389 | |
2390 ** Compilation | |
2391 | |
2392 *** Building Emacs over NFS fails with ``Text file busy''. | |
2393 | |
2394 This was reported to happen when building Emacs on a GNU/Linux system | |
2395 (RedHat Linux 6.2) using a build directory automounted from Solaris | |
2396 (SunOS 5.6) file server, but it might not be limited to that | |
2397 configuration alone. Presumably, the NFS server doesn't commit the | |
2398 files' data to disk quickly enough, and the Emacs executable file is | |
2399 left ``busy'' for several seconds after Emacs has finished dumping | |
2400 itself. This causes the subsequent commands which invoke the dumped | |
2401 Emacs executable to fail with the above message. | |
2402 | |
2403 In some of these cases, a time skew between the NFS server and the | |
2404 machine where Emacs is built is detected and reported by GNU Make | |
2405 (it says that some of the files have modification time in the future). | |
2406 This might be a symptom of NFS-related problems. | |
2407 | |
2408 If the NFS server runs on Solaris, apply the Solaris patch 105379-05 | |
2409 (Sunos 5.6: /kernel/misc/nfssrv patch). If that doesn't work, or if | |
2410 you have a different version of the OS or the NFS server, you can | |
2411 force the NFS server to use 1KB blocks, which was reported to fix the | |
2412 problem albeit at a price of slowing down file I/O. You can force 1KB | |
2413 blocks by specifying the "-o rsize=1024,wsize=1024" options to the | |
2414 `mount' command, or by adding ",rsize=1024,wsize=1024" to the mount | |
2415 options in the appropriate system configuration file, such as | |
2416 `/etc/auto.home'. | |
2417 | |
2418 Alternatively, when Make fails due to this problem, you could wait for | |
2419 a few seconds and then invoke Make again. In one particular case, | |
2420 waiting for 10 or more seconds between the two Make invocations seemed | |
2421 to work around the problem. | |
2422 | |
2423 Similar problems can happen if your machine NFS-mounts a directory | |
2424 onto itself. Suppose the Emacs sources live in `/usr/local/src' and | |
2425 you are working on the host called `marvin'. Then an entry in the | |
2426 `/etc/fstab' file like the following is asking for trouble: | |
2427 | |
2428 marvin:/usr/local/src /usr/local/src ...options.omitted... | |
2429 | |
2430 The solution is to remove this line from `etc/fstab'. | |
2431 | |
2432 *** Building Emacs with GCC 2.9x fails in the `src' directory. | |
2433 | |
2434 This may happen if you use a development version of GNU `cpp' from one | |
2435 of the GCC snapshots between Oct 2000 and Feb 2001, or from a released | |
2436 version of GCC newer than 2.95.2 which was prepared around those | |
2437 dates; similar problems were reported with some snapshots of GCC 3.1 | |
2438 around Sep 30 2001. The preprocessor in those versions is | |
2439 incompatible with a traditional Unix cpp (e.g., it expands ".." into | |
2440 ". .", which breaks relative file names that reference the parent | |
2441 directory; or inserts TAB characters before lines that set Make | |
2442 variables). | |
2443 | |
2444 The solution is to make sure the preprocessor is run with the | |
2445 `-traditional' option. The `configure' script does that automatically | |
2446 when it detects the known problems in your cpp, but you might hit some | |
2447 unknown ones. To force the `configure' script to use `-traditional', | |
2448 run the script like this: | |
2449 | |
2450 CPP='gcc -E -traditional' ./configure ... | |
2451 | |
2452 (replace the ellipsis "..." with any additional arguments you pass to | |
2453 the script). | |
2454 | |
2455 Note that this problem does not pertain to the MS-Windows port of | |
2456 Emacs, since it doesn't use the preprocessor to generate Makefiles. | |
2457 | |
2458 *** src/Makefile and lib-src/Makefile are truncated--most of the file missing. | |
2459 *** Compiling wakeup, in lib-src, says it can't make wakeup.c. | |
2460 | |
2461 This can happen if configure uses GNU sed version 2.03. That version | |
2462 had a bug. GNU sed version 2.05 works properly.To solve the | |
2463 problem, install the current version of GNU Sed, then rerun Emacs's | |
2464 configure script. | |
2465 | |
2466 *** Compiling lib-src says there is no rule to make test-distrib.c. | |
2467 | |
2468 This results from a bug in a VERY old version of GNU Sed. To solve | |
2469 the problem, install the current version of GNU Sed, then rerun | |
2470 Emacs's configure script. | |
2471 | |
2472 *** Building the MS-Windows port with Cygwin GCC can fail. | |
2473 | |
2474 Emacs may not build using recent Cygwin builds of GCC, such as Cygwin | |
2475 version 1.1.8, using the default configure settings. It appears to be | |
2476 necessary to specify the -mwin32 flag when compiling, and define | |
2477 __MSVCRT__, like so: | |
2478 | |
2479 configure --with-gcc --cflags -mwin32 --cflags -D__MSVCRT__ | |
2480 | |
2481 *** Building the MS-Windows port fails with a CreateProcess failure. | |
2482 | |
2483 Some versions of mingw32 make on some versions of Windows do not seem | |
2484 to detect the shell correctly. Try "make SHELL=cmd.exe", or if that | |
2485 fails, try running make from Cygwin bash instead. | |
2486 | |
2487 *** Building the MS-Windows port with Leim fails in the `leim' directory. | |
2488 | |
2489 The error message might be something like this: | |
2490 | |
2491 Converting d:/emacs-21.3/leim/CXTERM-DIC/4Corner.tit to quail-package... | |
2492 Invalid ENCODE: value in TIT dictionary | |
2493 NMAKE : fatal error U1077: '"../src/obj-spd/i386/emacs.exe"' : return code | |
2494 '0xffffffff' | |
2495 Stop. | |
2496 | |
2497 This can happen if the Leim distribution is unpacked with a program | |
2498 which converts the `*.tit' files to DOS-style CR-LF text format. The | |
2499 `*.tit' files in the leim/CXTERM-DIC directory require Unix-style line | |
2500 endings to compile properly, because Emacs reads them without any code | |
2501 or EOL conversions. | |
2502 | |
2503 The solution is to make sure the program used to unpack Leim does not | |
2504 change the files' line endings behind your back. The GNU FTP site has | |
2505 in the `/gnu/emacs/windows' directory a program called `djtarnt.exe' | |
2506 which can be used to unpack `.tar.gz' and `.zip' archives without | |
2507 mangling them. | |
2508 | |
2509 *** Building `ctags' for MS-Windows with the MinGW port of GCC fails. | |
2510 | |
2511 This might happen due to a bug in the MinGW header assert.h, which | |
2512 defines the `assert' macro with a trailing semi-colon. The following | |
2513 patch to assert.h should solve this: | |
2514 | |
2515 *** include/assert.h.orig Sun Nov 7 02:41:36 1999 | |
2516 --- include/assert.h Mon Jan 29 11:49:10 2001 | |
2517 *************** | |
2518 *** 41,47 **** | |
2519 /* | |
2520 * If not debugging, assert does nothing. | |
2521 */ | |
2522 ! #define assert(x) ((void)0); | |
2523 | |
2524 #else /* debugging enabled */ | |
2525 | |
2526 --- 41,47 ---- | |
2527 /* | |
2528 * If not debugging, assert does nothing. | |
2529 */ | |
2530 ! #define assert(x) ((void)0) | |
2531 | |
2532 #else /* debugging enabled */ | |
2533 | |
2534 | |
2535 ** Linking | |
2536 | |
2537 *** Building Emacs with a system compiler fails to link because of an | |
2538 undefined symbol such as __eprintf which does not appear in Emacs. | |
2539 | |
2540 This can happen if some of the libraries linked into Emacs were built | |
2541 with GCC, but Emacs itself is being linked with a compiler other than | |
2542 GCC. Object files compiled with GCC might need some helper functions | |
2543 from libgcc.a, the library which comes with GCC, but the system | |
2544 compiler does not instruct the linker to search libgcc.a during the | |
2545 link stage. | |
2546 | |
2547 A solution is to link with GCC, like this: | |
2548 | |
2549 make CC=gcc | |
2550 | |
2551 Since the .o object files already exist, this will not recompile Emacs | |
2552 with GCC, but just restart by trying again to link temacs. | |
2553 | |
2554 *** AIX 1.3 ptf 0013: Link failure. | |
2555 | |
2556 There is a real duplicate definition of the function `_slibc_free' in | |
2557 the library /lib/libc_s.a (just do nm on it to verify). The | |
2558 workaround/fix is: | |
2559 | |
2560 cd /lib | |
2561 ar xv libc_s.a NLtmtime.o | |
2562 ar dv libc_s.a NLtmtime.o | |
2563 | |
2564 *** AIX 4.1.2: Linker error messages such as | |
2565 ld: 0711-212 SEVERE ERROR: Symbol .__quous, found in the global symbol table | |
2566 of archive /usr/lib/libIM.a, was not defined in archive member shr.o. | |
2567 | |
2568 This is a problem in libIM.a. You can work around it by executing | |
2569 these shell commands in the src subdirectory of the directory where | |
2570 you build Emacs: | |
2571 | |
2572 cp /usr/lib/libIM.a . | |
2573 chmod 664 libIM.a | |
2574 ranlib libIM.a | |
2575 | |
2576 Then change -lIM to ./libIM.a in the command to link temacs (in | |
2577 Makefile). | |
2578 | |
2579 *** Sun with acc: Link failure when using acc on a Sun. | |
2580 | |
2581 To use acc, you need additional options just before the libraries, such as | |
2582 | |
2583 /usr/lang/SC2.0.1/values-Xt.o -L/usr/lang/SC2.0.1/cg87 -L/usr/lang/SC2.0.1 | |
2584 | |
2585 and you need to add -lansi just before -lc. | |
2586 | |
2587 The precise file names depend on the compiler version, so we | |
2588 cannot easily arrange to supply them. | |
2589 | |
2590 *** Linking says that the functions insque and remque are undefined. | |
2591 | |
2592 Change oldXMenu/Makefile by adding insque.o to the variable OBJS. | |
2593 | |
2594 *** `tparam' reported as a multiply-defined symbol when linking with ncurses. | |
2595 | |
2596 This problem results from an incompatible change in ncurses, in | |
2597 version 1.9.9e approximately. This version is unable to provide a | |
2598 definition of tparm without also defining tparam. This is also | |
2599 incompatible with Terminfo; as a result, the Emacs Terminfo support | |
2600 does not work with this version of ncurses. | |
2601 | |
2602 The fix is to install a newer version of ncurses, such as version 4.2. | |
2603 | |
2604 ** Dumping | |
2605 | |
2606 *** Linux: Segfault during `make bootstrap' under certain recent versions of the Linux kernel. | |
2607 | |
2608 With certain recent Linux kernels (like the one of Redhat Fedora Core | |
2609 1), the new "Exec-shield" functionality is enabled by default, which | |
2610 creates a different memory layout that breaks the emacs dumper. | |
2611 | |
2612 You can check the Exec-shield state like this: | |
2613 | |
2614 cat /proc/sys/kernel/exec-shield | |
2615 | |
2616 It returns 1 or 2 when Exec-shield is enabled, 0 otherwise. Please | |
2617 read your system documentation for more details on Exec-shield and | |
2618 associated commands. | |
2619 | |
2620 When Exec-shield is enabled, building Emacs will segfault during the | |
2621 execution of this command: | |
2622 | |
2623 temacs --batch --load loadup [dump|bootstrap] | |
2624 | |
2625 To work around this problem, it is necessary to temporarily disable | |
2626 Exec-shield while building Emacs, using the `setarch' command like | |
2627 this: | |
2628 | |
2629 setarch i386 ./configure <configure parameters> | |
2630 setarch i386 make <make parameters> | |
2631 | |
2632 *** Fatal signal in the command temacs -l loadup inc dump. | |
2633 | |
2634 This command is the final stage of building Emacs. It is run by the | |
2635 Makefile in the src subdirectory, or by build.com on VMS. | |
2636 | |
2637 It has been known to get fatal errors due to insufficient swapping | |
2638 space available on the machine. | |
2639 | |
2640 On 68000s, it has also happened because of bugs in the | |
2641 subroutine `alloca'. Verify that `alloca' works right, even | |
2642 for large blocks (many pages). | |
2643 | |
2644 *** test-distrib says that the distribution has been clobbered. | |
2645 *** or, temacs prints "Command key out of range 0-127". | |
2646 *** or, temacs runs and dumps emacs, but emacs totally fails to work. | |
2647 *** or, temacs gets errors dumping emacs. | |
2648 | |
2649 This can be because the .elc files have been garbled. Do not be | |
2650 fooled by the fact that most of a .elc file is text: these are | |
2651 binary files and can contain all 256 byte values. | |
2652 | |
2653 In particular `shar' cannot be used for transmitting GNU Emacs. | |
2654 It typically truncates "lines". What appear to be "lines" in | |
2655 a binary file can of course be of any length. Even once `shar' | |
2656 itself is made to work correctly, `sh' discards null characters | |
2657 when unpacking the shell archive. | |
2658 | |
2659 I have also seen character \177 changed into \377. I do not know | |
2660 what transfer means caused this problem. Various network | |
2661 file transfer programs are suspected of clobbering the high bit. | |
2662 | |
2663 If you have a copy of Emacs that has been damaged in its | |
2664 nonprinting characters, you can fix them: | |
2665 | |
2666 1) Record the names of all the .elc files. | |
2667 2) Delete all the .elc files. | |
2668 3) Recompile alloc.c with a value of PURESIZE twice as large. | |
2669 (See puresize.h.) You might as well save the old alloc.o. | |
2670 4) Remake emacs. It should work now. | |
2671 5) Running emacs, do Meta-x byte-compile-file repeatedly | |
2672 to recreate all the .elc files that used to exist. | |
2673 You may need to increase the value of the variable | |
2674 max-lisp-eval-depth to succeed in running the compiler interpreted | |
2675 on certain .el files. 400 was sufficient as of last report. | |
2676 6) Reinstall the old alloc.o (undoing changes to alloc.c if any) | |
2677 and remake temacs. | |
2678 7) Remake emacs. It should work now, with valid .elc files. | |
2679 | |
2680 *** temacs prints "Pure Lisp storage exhausted". | |
2681 | |
2682 This means that the Lisp code loaded from the .elc and .el | |
2683 files during temacs -l loadup inc dump took up more | |
2684 space than was allocated. | |
2685 | |
2686 This could be caused by | |
2687 1) adding code to the preloaded Lisp files | |
2688 2) adding more preloaded files in loadup.el | |
2689 3) having a site-init.el or site-load.el which loads files. | |
2690 Note that ANY site-init.el or site-load.el is nonstandard; | |
2691 if you have received Emacs from some other site | |
2692 and it contains a site-init.el or site-load.el file, consider | |
2693 deleting that file. | |
2694 4) getting the wrong .el or .elc files | |
2695 (not from the directory you expected). | |
2696 5) deleting some .elc files that are supposed to exist. | |
2697 This would cause the source files (.el files) to be | |
2698 loaded instead. They take up more room, so you lose. | |
2699 6) a bug in the Emacs distribution which underestimates | |
2700 the space required. | |
2701 | |
2702 If the need for more space is legitimate, change the definition | |
2703 of PURESIZE in puresize.h. | |
2704 | |
2705 But in some of the cases listed above, this problem is a consequence | |
2706 of something else that is wrong. Be sure to check and fix the real | |
2707 problem. | |
2708 | |
2709 *** Linux: Emacs crashes when dumping itself on Mac PPC running Yellow Dog GNU/Linux. | |
2710 | |
2711 The crashes happen inside the function Fmake_symbol; here's a typical | |
2712 C backtrace printed by GDB: | |
2713 | |
2714 0x190c0c0 in Fmake_symbol () | |
2715 (gdb) where | |
2716 #0 0x190c0c0 in Fmake_symbol () | |
2717 #1 0x1942ca4 in init_obarray () | |
2718 #2 0x18b3500 in main () | |
2719 #3 0x114371c in __libc_start_main (argc=5, argv=0x7ffff5b4, envp=0x7ffff5cc, | |
2720 | |
2721 This could happen because GCC version 2.95 and later changed the base | |
2722 of the load address to 0x10000000. Emacs needs to be told about this, | |
2723 but we currently cannot do that automatically, because that breaks | |
2724 other versions of GNU/Linux on the MacPPC. Until we find a way to | |
2725 distinguish between the Yellow Dog and the other varieties of | |
2726 GNU/Linux systems on the PPC, you will have to manually uncomment the | |
2727 following section near the end of the file src/m/macppc.h in the Emacs | |
2728 distribution: | |
2729 | |
2730 #if 0 /* This breaks things on PPC GNU/Linux except for Yellowdog, | |
2731 even with identical GCC, as, ld. Let's take it out until we | |
2732 know what's really going on here. */ | |
2733 /* GCC 2.95 and newer on GNU/Linux PPC changed the load address to | |
2734 0x10000000. */ | |
2735 #if defined __linux__ | |
2736 #if __GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 95) | |
2737 #define DATA_SEG_BITS 0x10000000 | |
2738 #endif | |
2739 #endif | |
2740 #endif /* 0 */ | |
2741 | |
2742 Remove the "#if 0" and "#endif" directives which surround this, save | |
2743 the file, and then reconfigure and rebuild Emacs. The dumping process | |
2744 should now succeed. | |
2745 | |
2746 *** HPUX 10.20: Emacs crashes during dumping on the HPPA machine. | |
2747 | |
2748 This seems to be due to a GCC bug; it is fixed in GCC 2.8.1. | |
2749 | |
2750 ** Installation | |
2751 | |
2752 *** Installing Emacs gets an error running `install-info'. | |
2753 | |
2754 You need to install a recent version of Texinfo; that package | |
2755 supplies the `install-info' command. | |
2756 | |
2757 ** First execution | |
2758 | |
2759 *** Emacs binary is not in executable format, and cannot be run. | |
2760 | |
2761 This was reported to happen when Emacs is built in a directory mounted | |
2762 via NFS, for some combinations of NFS client and NFS server. | |
2763 Usually, the file `emacs' produced in these cases is full of | |
2764 binary null characters, and the `file' utility says: | |
2765 | |
2766 emacs: ASCII text, with no line terminators | |
2767 | |
2768 We don't know what exactly causes this failure. A work-around is to | |
2769 build Emacs in a directory on a local disk. | |
2770 | |
2771 *** The dumped Emacs crashes when run, trying to write pure data. | |
2772 | |
2773 Two causes have been seen for such problems. | |
2774 | |
2775 1) On a system where getpagesize is not a system call, it is defined | |
2776 as a macro. If the definition (in both unexec.c and malloc.c) is wrong, | |
2777 it can cause problems like this. You might be able to find the correct | |
2778 value in the man page for a.out (5). | |
2779 | |
2780 2) Some systems allocate variables declared static among the | |
2781 initialized variables. Emacs makes all initialized variables in most | |
2782 of its files pure after dumping, but the variables declared static and | |
2783 not initialized are not supposed to be pure. On these systems you | |
2784 may need to add "#define static" to the m- or the s- file. | |
2785 | |
2786 * Emacs 19 problems | |
2787 | |
2788 ** Error messages `Wrong number of arguments: #<subr where-is-internal>, 5'. | |
2789 | |
2790 This typically results from having the powerkey library loaded. | |
2791 Powerkey was designed for Emacs 19.22. It is obsolete now because | |
2792 Emacs 19 now has this feature built in; and powerkey also calls | |
2793 where-is-internal in an obsolete way. | |
2794 | |
2795 So the fix is to arrange not to load powerkey. | |
2796 | |
2797 * Runtime problems on legacy systems | |
2798 | |
2799 This section covers bugs reported on very old hardware or software. | |
2800 If you are using hardware and an operating system shipped after 2000, | |
2801 it is unlikely you will see any of these. | |
2802 | |
2803 ** Ancient operating systems | |
2804 | |
2805 *** ISC Unix | |
2806 | |
2807 **** ISC: display-time causes kernel problems on ISC systems. | |
2808 | |
2809 Under Interactive Unix versions 3.0.1 and 4.0 (and probably other | |
2810 versions), display-time causes the loss of large numbers of STREVENT | |
2811 cells. Eventually the kernel's supply of these cells is exhausted. | |
2812 This makes emacs and the whole system run slow, and can make other | |
2813 processes die, in particular pcnfsd. | |
2814 | |
2815 Other emacs functions that communicate with remote processes may have | |
2816 the same problem. Display-time seems to be far the worst. | |
2817 | |
2818 The only known fix: Don't run display-time. | |
2819 | |
2820 *** SunOS | |
2821 | |
2822 **** Sun 4.0.x: M-x shell persistently reports "Process shell exited abnormally with code 1". | |
2823 | |
2824 This happened on Suns as a result of what is said to be a bug in Sunos | |
2825 version 4.0.x. The only fix was to reboot the machine. | |
2826 | |
2827 **** SunOS4.1.1 and SunOS4.1.3: Mail is lost when sent to local aliases. | |
2828 | |
2829 Many emacs mail user agents (VM and rmail, for instance) use the | |
2830 sendmail.el library. This library can arrange for mail to be | |
2831 delivered by passing messages to the /usr/lib/sendmail (usually) | |
2832 program . In doing so, it passes the '-t' flag to sendmail, which | |
2833 means that the name of the recipient of the message is not on the | |
2834 command line and, therefore, that sendmail must parse the message to | |
2835 obtain the destination address. | |
2836 | |
2837 There is a bug in the SunOS4.1.1 and SunOS4.1.3 versions of sendmail. | |
2838 In short, when given the -t flag, the SunOS sendmail won't recognize | |
2839 non-local (i.e. NIS) aliases. It has been reported that the Solaris | |
2840 2.x versions of sendmail do not have this bug. For those using SunOS | |
2841 4.1, the best fix is to install sendmail V8 or IDA sendmail (which | |
2842 have other advantages over the regular sendmail as well). At the time | |
2843 of this writing, these official versions are available: | |
2844 | |
2845 Sendmail V8 on ftp.cs.berkeley.edu in /ucb/sendmail: | |
2846 sendmail.8.6.9.base.tar.Z (the base system source & documentation) | |
2847 sendmail.8.6.9.cf.tar.Z (configuration files) | |
2848 sendmail.8.6.9.misc.tar.Z (miscellaneous support programs) | |
2849 sendmail.8.6.9.xdoc.tar.Z (extended documentation, with postscript) | |
2850 | |
2851 IDA sendmail on vixen.cso.uiuc.edu in /pub: | |
2852 sendmail-5.67b+IDA-1.5.tar.gz | |
2853 | |
2854 **** Sunos 5.3: Subprocesses remain, hanging but not zombies. | |
2855 | |
2856 A bug in Sunos 5.3 causes Emacs subprocesses to remain after Emacs | |
2857 exits. Sun patch # 101415-02 is part of the fix for this, but it only | |
2858 applies to ptys, and doesn't fix the problem with subprocesses | |
2859 communicating through pipes. | |
2860 | |
2861 **** Sunos 4: You get the error ld: Undefined symbol __lib_version. | |
2862 | |
2863 This is the result of using cc or gcc with the shared library meant | |
2864 for acc (the Sunpro compiler). Check your LD_LIBRARY_PATH and delete | |
2865 /usr/lang/SC2.0.1 or some similar directory. | |
2866 | |
2867 **** SunOS 4.1.3: Emacs unpredictably crashes in _yp_dobind_soft. | |
2868 | |
2869 This happens if you configure Emacs specifying just `sparc-sun-sunos4' | |
2870 on a system that is version 4.1.3. You must specify the precise | |
2871 version number (or let configure figure out the configuration, which | |
2872 it can do perfectly well for SunOS). | |
2873 | |
2874 **** Sunos 4.1.3: Emacs gets hung shortly after startup. | |
2875 | |
2876 We think this is due to a bug in Sunos. The word is that | |
2877 one of these Sunos patches fixes the bug: | |
2878 | |
2879 100075-11 100224-06 100347-03 100482-05 100557-02 100623-03 100804-03 101080-01 | |
2880 100103-12 100249-09 100496-02 100564-07 100630-02 100891-10 101134-01 | |
2881 100170-09 100296-04 100377-09 100507-04 100567-04 100650-02 101070-01 101145-01 | |
2882 100173-10 100305-15 100383-06 100513-04 100570-05 100689-01 101071-03 101200-02 | |
2883 100178-09 100338-05 100421-03 100536-02 100584-05 100784-01 101072-01 101207-01 | |
2884 | |
2885 We don't know which of these patches really matter. If you find out | |
2886 which ones, please inform bug-gnu-emacs@gnu.org. | |
2887 | |
2888 **** SunOS 4: Emacs processes keep going after you kill the X server | |
2889 (or log out, if you logged in using X). | |
2890 | |
2891 Someone reported that recompiling with GCC 2.7.0 fixed this problem. | |
2892 | |
2893 **** SunOS: You get linker errors | |
2894 ld: Undefined symbol | |
2895 _get_wmShellWidgetClass | |
2896 _get_applicationShellWidgetClass | |
2897 | |
2898 The fix to this is to install patch 100573 for OpenWindows 3.0 | |
2899 or link libXmu statically. | |
2900 | |
2901 *** Apollo Domain | |
2902 | |
2903 **** Shell mode ignores interrupts on Apollo Domain. | |
2904 | |
2905 You may find that M-x shell prints the following message: | |
2906 | |
2907 Warning: no access to tty; thus no job control in this shell... | |
2908 | |
2909 This can happen if there are not enough ptys on your system. | |
2910 Here is how to make more of them. | |
2911 | |
2912 % cd /dev | |
2913 % ls pty* | |
2914 # shows how many pty's you have. I had 8, named pty0 to pty7) | |
2915 % /etc/crpty 8 | |
2916 # creates eight new pty's | |
2917 | |
2918 *** Irix | |
2919 | |
2920 *** Irix 6.2: No visible display on mips-sgi-irix6.2 when compiling with GCC 2.8.1. | |
2921 | |
2922 This problem went away after installing the latest IRIX patches | |
2923 as of 8 Dec 1998. | |
2924 | |
2925 The same problem has been reported on Irix 6.3. | |
2926 | |
2927 *** Irix 6.3: substituting environment variables in file names | |
2928 in the minibuffer gives peculiar error messages such as | |
2929 | |
2930 Substituting nonexistent environment variable "" | |
2931 | |
2932 This is not an Emacs bug; it is caused by something in SGI patch | |
2933 003082 August 11, 1998. | |
2934 | |
2935 *** OPENSTEP | |
2936 | |
2937 **** OPENSTEP 4.2: Compiling syntax.c with gcc 2.7.2.1 fails. | |
2938 | |
2939 The compiler was reported to crash while compiling syntax.c with the | |
2940 following message: | |
2941 | |
2942 cc: Internal compiler error: program cc1obj got fatal signal 11 | |
2943 | |
2944 To work around this, replace the macros UPDATE_SYNTAX_TABLE_FORWARD, | |
2945 INC_BOTH, and INC_FROM with functions. To this end, first define 3 | |
2946 functions, one each for every macro. Here's an example: | |
2947 | |
2948 static int update_syntax_table_forward(int from) | |
2949 { | |
2950 return(UPDATE_SYNTAX_TABLE_FORWARD(from)); | |
2951 }/*update_syntax_table_forward*/ | |
2952 | |
2953 Then replace all references to UPDATE_SYNTAX_TABLE_FORWARD in syntax.c | |
2954 with a call to the function update_syntax_table_forward. | |
2955 | |
2956 *** Solaris 2.x | |
2957 | |
2958 **** Strange results from format %d in a few cases, on a Sun. | |
2959 | |
2960 Sun compiler version SC3.0 has been found to miscompile part of | |
2961 editfns.c. The workaround is to compile with some other compiler such | |
2962 as GCC. | |
2963 | |
2964 **** On Solaris, Emacs dumps core if lisp-complete-symbol is called. | |
2965 | |
2966 If you compile Emacs with the -fast or -xO4 option with version 3.0.2 | |
2967 of the Sun C compiler, Emacs dumps core when lisp-complete-symbol is | |
2968 called. The problem does not happen if you compile with GCC. | |
2969 | |
2970 **** On Solaris, Emacs crashes if you use (display-time). | |
2971 | |
2972 This can happen if you configure Emacs without specifying the precise | |
2973 version of Solaris that you are using. | |
2974 | |
2975 **** Solaris 2.3 and 2.4: Unpredictable segmentation faults. | |
2976 | |
2977 A user reported that this happened in 19.29 when it was compiled with | |
2978 the Sun compiler, but not when he recompiled with GCC 2.7.0. | |
2979 | |
2980 We do not know whether something in Emacs is partly to blame for this. | |
2981 | |
2982 **** Solaris 2.4: Emacs dumps core on startup. | |
2983 | |
2984 Bill Sebok says that the cause of this is Solaris 2.4 vendor patch | |
2985 102303-05, which extends the Solaris linker to deal with the Solaris | |
2986 Common Desktop Environment's linking needs. You can fix the problem | |
2987 by removing this patch and installing patch 102049-02 instead. | |
2988 However, that linker version won't work with CDE. | |
2989 | |
2990 Solaris 2.5 comes with a linker that has this bug. It is reported that if | |
2991 you install all the latest patches (as of June 1996), the bug is fixed. | |
2992 We suspect the crucial patch is one of these, but we don't know | |
2993 for certain. | |
2994 | |
2995 103093-03: [README] SunOS 5.5: kernel patch (2140557 bytes) | |
2996 102832-01: [README] OpenWindows 3.5: Xview Jumbo Patch (4181613 bytes) | |
2997 103242-04: [README] SunOS 5.5: linker patch (595363 bytes) | |
2998 | |
2999 (One user reports that the bug was fixed by those patches together | |
3000 with patches 102980-04, 103279-01, 103300-02, and 103468-01.) | |
3001 | |
3002 If you can determine which patch does fix the bug, please tell | |
3003 bug-gnu-emacs@gnu.org. | |
3004 | |
3005 Meanwhile, the GNU linker links Emacs properly on both Solaris 2.4 and | |
3006 Solaris 2.5. | |
3007 | |
3008 **** Solaris 2.4: Dired hangs and C-g does not work. Or Emacs hangs | |
3009 forever waiting for termination of a subprocess that is a zombie. | |
3010 | |
3011 casper@fwi.uva.nl says the problem is in X11R6. Rebuild libX11.so | |
3012 after changing the file xc/config/cf/sunLib.tmpl. Change the lines | |
3013 | |
3014 #if ThreadedX | |
3015 #define SharedX11Reqs -lthread | |
3016 #endif | |
3017 | |
3018 to: | |
3019 | |
3020 #if OSMinorVersion < 4 | |
3021 #if ThreadedX | |
3022 #define SharedX11Reqs -lthread | |
3023 #endif | |
3024 #endif | |
3025 | |
3026 Be sure also to edit x/config/cf/sun.cf so that OSMinorVersion is 4 | |
3027 (as it should be for Solaris 2.4). The file has three definitions for | |
3028 OSMinorVersion: the first is for x86, the second for SPARC under | |
3029 Solaris, and the third for SunOS 4. Make sure to update the | |
3030 definition for your type of machine and system. | |
3031 | |
3032 Then do `make Everything' in the top directory of X11R6, to rebuild | |
3033 the makefiles and rebuild X. The X built this way work only on | |
3034 Solaris 2.4, not on 2.3. | |
3035 | |
3036 For multithreaded X to work it is necessary to install patch | |
3037 101925-02 to fix problems in header files [2.4]. You need | |
3038 to reinstall gcc or re-run just-fixinc after installing that | |
3039 patch. | |
3040 | |
3041 However, Frank Rust <frust@iti.cs.tu-bs.de> used a simpler solution: | |
3042 he changed | |
3043 #define ThreadedX YES | |
3044 to | |
3045 #define ThreadedX NO | |
3046 in sun.cf and did `make World' to rebuild X11R6. Removing all | |
3047 `-DXTHREAD*' flags and `-lthread' entries from lib/X11/Makefile and | |
3048 typing 'make install' in that directory also seemed to work. | |
3049 | |
3050 **** Solaris 2.x: GCC complains "64 bit integer types not supported". | |
3051 | |
3052 This suggests that GCC is not installed correctly. Most likely you | |
3053 are using GCC 2.7.2.3 (or earlier) on Solaris 2.6 (or later); this | |
3054 does not work without patching. To run GCC 2.7.2.3 on Solaris 2.6 or | |
3055 later, you must patch fixinc.svr4 and reinstall GCC from scratch as | |
3056 described in the Solaris FAQ | |
3057 <http://www.wins.uva.nl/pub/solaris/solaris2.html>. A better fix is | |
3058 to upgrade to GCC 2.8.1 or later. | |
3059 | |
3060 **** Solaris 2.7: Building Emacs with WorkShop Compilers 5.0 98/12/15 | |
3061 C 5.0 failed, apparently with non-default CFLAGS, most probably due to | |
3062 compiler bugs. Using Sun Solaris 2.7 Sun WorkShop 6 update 1 C | |
3063 release was reported to work without problems. It worked OK on | |
3064 another system with Solaris 8 using apparently the same 5.0 compiler | |
3065 and the default CFLAGS. | |
3066 | |
3067 **** Solaris 2.x: Emacs dumps core when built with Motif. | |
3068 | |
3069 The Solaris Motif libraries are buggy, at least up through Solaris 2.5.1. | |
3070 Install the current Motif runtime library patch appropriate for your host. | |
3071 (Make sure the patch is current; some older patch versions still have the bug.) | |
3072 You should install the other patches recommended by Sun for your host, too. | |
3073 You can obtain Sun patches from ftp://sunsolve.sun.com/pub/patches/; | |
3074 look for files with names ending in `.PatchReport' to see which patches | |
3075 are currently recommended for your host. | |
3076 | |
3077 On Solaris 2.6, Emacs is said to work with Motif when Solaris patch | |
3078 105284-12 is installed, but fail when 105284-15 is installed. | |
3079 105284-18 might fix it again. | |
3080 | |
3081 *** Solaris 2.6 and 7: the Compose key does not work. | |
3082 | |
3083 This is a bug in Motif in Solaris. Supposedly it has been fixed for | |
3084 the next major release of Solaris. However, if someone with Sun | |
3085 support complains to Sun about the bug, they may release a patch. | |
3086 If you do this, mention Sun bug #4188711. | |
3087 | |
3088 One workaround is to use a locale that allows non-ASCII characters. | |
3089 For example, before invoking emacs, set the LC_ALL environment | |
3090 variable to "en_US" (American English). The directory /usr/lib/locale | |
3091 lists the supported locales; any locale other than "C" or "POSIX" | |
3092 should do. | |
3093 | |
3094 pen@lysator.liu.se says (Feb 1998) that the Compose key does work | |
3095 if you link with the MIT X11 libraries instead of the Solaris X11 | |
3096 libraries. | |
3097 | |
3098 *** Ultrix and Digital Unix | |
3099 | |
3100 **** Ultrix 4.2: `make install' fails on install-doc with `Error 141'. | |
3101 | |
3102 This happens on Ultrix 4.2 due to failure of a pipeline of tar | |
3103 commands. We don't know why they fail, but the bug seems not to be in | |
3104 Emacs. The workaround is to run the shell command in install-doc by | |
3105 hand. | |
3106 | |
3107 **** Digital Unix 4.0: Garbled display on non-X terminals when Emacs runs. | |
3108 | |
3109 So far it appears that running `tset' triggers this problem (when TERM | |
3110 is vt100, at least). If you do not run `tset', then Emacs displays | |
3111 properly. If someone can tell us precisely which effect of running | |
3112 `tset' actually causes the problem, we may be able to implement a fix | |
3113 in Emacs. | |
3114 | |
3115 **** Ultrix: `expand-file-name' fails to work on any but the machine you dumped Emacs on. | |
3116 | |
3117 On Ultrix, if you use any of the functions which look up information | |
3118 in the passwd database before dumping Emacs (say, by using | |
3119 expand-file-name in site-init.el), then those functions will not work | |
3120 in the dumped Emacs on any host but the one Emacs was dumped on. | |
3121 | |
3122 The solution? Don't use expand-file-name in site-init.el, or in | |
3123 anything it loads. Yuck - some solution. | |
3124 | |
3125 I'm not sure why this happens; if you can find out exactly what is | |
3126 going on, and perhaps find a fix or a workaround, please let us know. | |
3127 Perhaps the YP functions cache some information, the cache is included | |
3128 in the dumped Emacs, and is then inaccurate on any other host. | |
3129 | |
3130 *** SVr4 | |
3131 | |
3132 **** SVr4: On some variants of SVR4, Emacs does not work at all with X. | |
3133 | |
3134 Try defining BROKEN_FIONREAD in your config.h file. If this solves | |
3135 the problem, please send a bug report to tell us this is needed; be | |
3136 sure to say exactly what type of machine and system you are using. | |
3137 | |
3138 **** SVr4: After running emacs once, subsequent invocations crash. | |
3139 | |
3140 Some versions of SVR4 have a serious bug in the implementation of the | |
3141 mmap () system call in the kernel; this causes emacs to run correctly | |
3142 the first time, and then crash when run a second time. | |
3143 | |
3144 Contact your vendor and ask for the mmap bug fix; in the mean time, | |
3145 you may be able to work around the problem by adding a line to your | |
3146 operating system description file (whose name is reported by the | |
3147 configure script) that reads: | |
3148 #define SYSTEM_MALLOC | |
3149 This makes Emacs use memory less efficiently, but seems to work around | |
3150 the kernel bug. | |
3151 | |
3152 *** Linux 1.x | |
3153 | |
3154 **** Linux 1.0-1.04: Typing C-c C-c in Shell mode kills your X server. | |
3155 | |
3156 This happens with Linux kernel 1.0 thru 1.04, approximately. The workaround is | |
3157 to define SIGNALS_VIA_CHARACTERS in config.h and recompile Emacs. | |
3158 Newer Linux kernel versions don't have this problem. | |
3159 | |
3160 **** Linux 1.3: Output from subprocess (such as man or diff) is randomly | |
3161 truncated on GNU/Linux systems. | |
3162 | |
3163 This is due to a kernel bug which seems to be fixed in Linux version | |
3164 1.3.75. | |
3165 | 3170 |
3166 ** MS-DOS | 3171 ** MS-DOS |
3167 | 3172 |
3168 *** When compiling with DJGPP on MS-Windows NT, "config msdos" fails. | 3173 *** When compiling with DJGPP on MS-Windows NT, "config msdos" fails. |
3169 | 3174 |
3375 toolkit.) | 3380 toolkit.) |
3376 | 3381 |
3377 If you get the additional error that the linker could not find | 3382 If you get the additional error that the linker could not find |
3378 lib_version.o, try extracting it from X11/usr/lib/X11/libvim.a in | 3383 lib_version.o, try extracting it from X11/usr/lib/X11/libvim.a in |
3379 X11R4, then use it in the link. | 3384 X11R4, then use it in the link. |
3385 | |
3386 ** SunOS4, DGUX 5.4.2: --with-x-toolkit version crashes when used with shared libraries. | |
3387 | |
3388 On some systems, including Sunos 4 and DGUX 5.4.2 and perhaps others, | |
3389 unexec doesn't work properly with the shared library for the X | |
3390 toolkit. You might be able to work around this by using a nonshared | |
3391 libXt.a library. The real fix is to upgrade the various versions of | |
3392 unexec and/or ralloc. We think this has been fixed on Sunos 4 | |
3393 and Solaris in version 19.29. | |
3394 | |
3395 ** HPUX 10.20: Emacs crashes during dumping on the HPPA machine. | |
3396 | |
3397 This seems to be due to a GCC bug; it is fixed in GCC 2.8.1. | |
3380 | 3398 |
3381 ** VMS: Compilation errors on VMS. | 3399 ** VMS: Compilation errors on VMS. |
3382 | 3400 |
3383 You will get warnings when compiling on VMS because there are | 3401 You will get warnings when compiling on VMS because there are |
3384 variable names longer than 32 (or whatever it is) characters. | 3402 variable names longer than 32 (or whatever it is) characters. |