IntroductionThis is part 2 of the XEmacs Frequently Asked Questions list. This section is devoted to Installation, Maintenance and Trouble Shooting.
If you have a Web browser, the official hypertext version is at: <http://www.sccon.com/~andreas/xemacs-installation.html>, and also at: <http://www.xemacs.org/faq/xemacs-installation.html>. This version is much nicer than the unofficial hypertext versions that are archived at Utrecht, Oxford, Smart Pages, Ohio State, and other FAQ archives.
Changes this month:
This file was last modified on Feburary 23, 1998.
Roadmap![[You are here]](lcylarrw.gif)
create_process failure
strcat on HP/UX 10
2.0 Installation
Q2.0.1 Running XEmacs without installingXEmacs will run in place without requiring installation and copying of the Lisp directories, and without having to specify a special build-time flag. It's the copying of the Lisp directories that requires so much space. XEmacs is largely written in Lisp.
A good method is to make a shell alias for xemacs:
alias xemacs=/i/xemacs-20.2/src/xemacs(You will obviously use whatever directory you downloaded the source tree to instead of /i/xemacs-20.2).
This will let you run XEmacs without massive copying.
Q2.0.2 XEmacs is too big
Steve Baur <steve@altair.xemacs.org> writes:
The 45MB of space required by the installation directories can be reduced dramatically if desired. Gzip all the .el files. Remove all the packages you'll never want to use (or even ones you do like the two obsolete mailcrypts and Gnus 4 in 19.13). Remove the TexInfo manuals. Remove the Info (and use just hardcopy versions of the manual). Remove most of the stuff in etc. Remove or gzip all the source code. Gzip or remove the C source code. Configure it so that copies are not made of the support lisp. I'm not advocating any of these things, just pointing out ways to reduce the disk requirements if desired.
Now examine the space used by directory:
0 /usr/local/bin/xemacs 2048 /usr/local/bin/xemacs-19.13 1546 /usr/local/lib/xemacs-19.13/i486-miranova-sco3.2v4.2 1158 /usr/local/lib/xemacs-19.13/i486-unknown-linux1.2.13You need to keep these. XEmacs isn't stripped by default in installation, you should consider stripping. That will save you about 5MB right there.
207 /usr/local/lib/xemacs-19.13/etc/w3 122 /usr/local/lib/xemacs-19.13/etc/sounds 18 /usr/local/lib/xemacs-19.13/etc/sparcworks 159 /usr/local/lib/xemacs-19.13/etc/vm 6 /usr/local/lib/xemacs-19.13/etc/e 21 /usr/local/lib/xemacs-19.13/etc/eos 172 /usr/local/lib/xemacs-19.13/etc/toolbar 61 /usr/local/lib/xemacs-19.13/etc/ns 43 /usr/local/lib/xemacs-19.13/etc/gnusThese are support directories for various packages. In general they match a directory under ./xemacs-19.13/lib/xemacs-19.13/lisp/. If you do not require the package, you may delete or gzip the support too.
1959 /usr/local/lib/xemacs-19.13/etc 175 /usr/local/lib/xemacs-19.13/lisp/bytecomp 340 /usr/local/lib/xemacs-19.13/lisp/calendar 342 /usr/local/lib/xemacs-19.13/lisp/comint 517 /usr/local/lib/xemacs-19.13/lisp/dired 42 /usr/local/lib/xemacs-19.13/lisp/electric 212 /usr/local/lib/xemacs-19.13/lisp/emulators 238 /usr/local/lib/xemacs-19.13/lisp/energize 289 /usr/local/lib/xemacs-19.13/lisp/gnus 457 /usr/local/lib/xemacs-19.13/lisp/ilisp 1439 /usr/local/lib/xemacs-19.13/lisp/modes 2276 /usr/local/lib/xemacs-19.13/lisp/packages 1040 /usr/local/lib/xemacs-19.13/lisp/prim 176 /usr/local/lib/xemacs-19.13/lisp/pcl-cvs 154 /usr/local/lib/xemacs-19.13/lisp/rmail 3 /usr/local/lib/xemacs-19.13/lisp/epoch 45 /usr/local/lib/xemacs-19.13/lisp/term 860 /usr/local/lib/xemacs-19.13/lisp/utils 851 /usr/local/lib/xemacs-19.13/lisp/vm 13 /usr/local/lib/xemacs-19.13/lisp/vms 157 /usr/local/lib/xemacs-19.13/lisp/x11 19 /usr/local/lib/xemacs-19.13/lisp/tooltalk 14 /usr/local/lib/xemacs-19.13/lisp/sunpro 291 /usr/local/lib/xemacs-19.13/lisp/games 198 /usr/local/lib/xemacs-19.13/lisp/edebug 619 /usr/local/lib/xemacs-19.13/lisp/w3 229 /usr/local/lib/xemacs-19.13/lisp/eos 55 /usr/local/lib/xemacs-19.13/lisp/iso 59 /usr/local/lib/xemacs-19.13/lisp/mailcrypt 187 /usr/local/lib/xemacs-19.13/lisp/eterm 356 /usr/local/lib/xemacs-19.13/lisp/ediff 408 /usr/local/lib/xemacs-19.13/lisp/hyperbole/kotl 1262 /usr/local/lib/xemacs-19.13/lisp/hyperbole 247 /usr/local/lib/xemacs-19.13/lisp/hm--html-menus 161 /usr/local/lib/xemacs-19.13/lisp/mh-e 299 /usr/local/lib/xemacs-19.13/lisp/viper 53 /usr/local/lib/xemacs-19.13/lisp/oobr/tree-x 4 /usr/local/lib/xemacs-19.13/lisp/oobr/tree-nx/English.lproj/DocWindow.nib 3 /usr/local/lib/xemacs-19.13/lisp/oobr/tree-nx/English.lproj/InfoPanel.nib 3 /usr/local/lib/xemacs-19.13/lisp/oobr/tree-nx/English.lproj/TreeView.nib 11 /usr/local/lib/xemacs-19.13/lisp/oobr/tree-nx/English.lproj 53 /usr/local/lib/xemacs-19.13/lisp/oobr/tree-nx 466 /usr/local/lib/xemacs-19.13/lisp/oobr 14142 /usr/local/lib/xemacs-19.13/lispThese are all Emacs Lisp source code and bytecompiled object code. You may safely gzip everything named *.el here. You may remove any package you don't use. Nothing bad will happen if you delete a package that you do not use. You must be sure you do not use it though, so be conservative at first.
Possible candidates for deletion include w3 (newer versions exist, or you may just use Lynx or Netscape for web browsing), games, hyperbole, mh-e, hm--html-menus (better packages exist), vm, viper, oobr, gnus (new versions exist), etc. Ask yourself, Do I ever want to use this package? If the answer is no, then it is a candidate for removal.
First, gzip all the .el files. Then go about package by package and start gzipping the .elc files. Then run XEmacs and do whatever it is you normally do. If nothing bad happens, then delete the directory. Be conservative about deleting directories, and it would be handy to have a backup tape around in case you get too zealous.
prim, modes, packages, and utils are four directories you definitely do not want to delete, although certain packages can be removed from them if you do not use them.
1972 /usr/local/lib/xemacs-19.13/infoThese are online texinfo sources. You may either gzip them or remove them. In either case, C-h i (info mode) will no longer work.
20778 /usr/local/lib/xemacs-19.13The 20MB achieved is less than half of what the full distribution takes up, and can be achieved without deleting a single file.
giacomo boffi boffi@hp735.stru.polimi.it provides this procedure:
Substitute /usr/local/lib/ with the path where the xemacs tree is
rooted, then use this script:
#!/bin/sh
r=/usr/local/lib/xemacs-19.13/lisp
cd $r ; rm -f cmpr ; touch cmpr
du -s .
for d in * ; do
if test -d $d ; then
cd $d
for f in *.el ; do
# compress (remove) only (ONLY) the sources that have a
# corresponding compiled file --- do not (DO NOT) touch other
# sources
if test -f $@{f@}c ; then gzip -v9 $f >> $r/cmpr ; fi
done
cd ..
fi
done
du -s .
A step beyond would be substituting rm -f for gzip -v9,
but you have to be desperate for removing the sources (remember that
emacs can access compressed files transparently).
Also, a good megabyte could easily be trimmed from the $r/../etc directory, e.g., the termcap files, some O+NEWS, others that I don't remember as well.
XEmacs 20.3 will unbundle the lisp hierarchy and allow the installer to choose exactly how much support code gets installed.
Q2.0.3 Compiling XEmacs with NetaudioYou should only need to add some stuff to the configure command line. To tell it to compile in netaudio support: --with-sound=both, or --with-sound=nas if you don't want native sound support for some reason.) To tell it where to find the netaudio includes and libraries:
--site-libraries=WHATEVER --site-includes=WHATEVERThen (fingers crossed) it should compile and it will use netaudio if you have a server running corresponding to the X server. The netaudio server has to be there when XEmacs starts. If the netaudio server goes away and another is run, XEmacs should cope (fingers crossed, error handling in netaudio isn't perfect).
BTW, netaudio has been renamed as it has a name clash with something else, so if you see references to NAS or Network Audio System, it's the same thing. It also might be found at <ftp://ftp.x.org:/contrib/audio/nas/>
Q2.0.4 Problems with Linux and ncurses.src/xemacs -nw -q Initialization error: Terminal type `xterm' undefined (or can't access database?)Ben Wing <ben@666.com> writes:
Q2.0.5 Do I need X11 to run XEmacs?Q2.0.6 I'm having strange crashes. What do I do?Q2.0.7 Libraries in non-standard locations
--site-libraries='/path/one /path/two /path/etc'
Q2.0.8 can't resolve symbol _h_errno
perl -pi -e 's/_h_errno\0/h_errno\0\0/g' /usr/local/bin/xemacs-19.15NB: You must patch /usr/local/bin/xemacs-19.14, and not xemacs because xemacs is a link to xemacs-19.14; the Perl -i option will cause unwanted side-effects if applied to a symbolic link.
Steve L. Baur <steve@miranova.com> writes:
If you build against a recent libc-5.4 (late enough to have caused problems earlier in the beta cycle) and then run with an earlier version of libc, you get a
$ xemacs
xemacs: can't resolve symbol '__malloc_hook'
zsh: 7942 segmentation fault (core dumped) xemacs
(Example binary compiled against libc-5.4.23 and run with libc-5.4.16).
The solution is to upgrade to at least libc-5.4.23. Sigh. Drat.
Q2.0.9 Where do I find external libraries?
Q2.0.10 After I run configure I find a coredump, is something wrong?sed 3.0 has been withdrawn from distribution. It has major revisions, which mostly seem to be improvements; but it turns out to have bugs too which cause trouble in some common cases.
Tom Lord won't be able to work fixing the bugs until May. So in the mean time, we've decided to withdraw sed 3.0 from distribution and make version 2.05 once again the recommended version.
It has also been observed that the vfork test on Solaris will leave a coredump.
Q2.0.11 XEmacs doesn't resolve hostnamesChristopher Davis <ckd@loiosh.kei.com> writes:
That's correct [The SunOS 4.1.3 precompiled binaries don't do name lookup]. Since Sun figured that everyone used NIS to do name lookups (that DNS thing was apparently only a passing fad, right?), the stock SunOS 4.x systems don't have DNS-based name lookups in libc.
This is also why Netscape ships two binaries for SunOS 4.1.x.
The best solution is to compile it yourself; the configure script will check to see if you've put DNS in the shared libc and will then proceed to link against the DNS resolver library code.
Q2.0.12 Why can't I strip XEmacs?Because of the way XEmacs (and every other Emacsen, AFAIK) is built. The link gives you a bare-boned emacs (called temacs). temacs is then run, preloading some of the lisp files. The result is then dumped into a new executable, named xemacs, which will contain all of the preloaded lisp functions and data.
Now, during the dump itself, the executable (code+data+symbols) is written on disk using a special unexec() function. This function is obviously heavily system dependent. And on some systems, it leads to an executable which, although valid, cannot be stripped without damage. If memory serves, this is especially the case for AIX binaries. On other architecture it might work OK.
The Right Way to strip the emacs binary is to strip temacs prior to dumping xemacs. This will always work, although you can do that only if you install from sources (as temacs is not part of the binary kits).
Nat Makarevitch <nat@nataa.fr.eu.org> writes:
Here is the trick:
Q2.0.13 Problems linking with Gcc on Solaris>unexec(): dlopen(../dynodump/dynodump.so): ld.so.1: ./temacs: fatal: relocation error: symbol not found: main: referenced in ../dynodump/dynodump.soMartin Buchholz <mrb@eng.sun.com> writes:
You need to specify -fno-gnu-linker as part of your flags to pass to ld. Future releases of XEmacs will try to do this automatically.
Q2.0.14 Make on HP/UX 9 fails after linking temacsProblem when building xemacs-19.15 on hpux 9:
Richard Cognot lt&;cognot@ensg.u-nancy.fr> writes:
make on hpux fails after linking temacs with a message:
"make: don't know how to make .y."
Solution: This is a problem with HP make revision 70.X. Either use GNU make, or install PHCO_6552, which will bring make to revision 72.24.1.17.
2.1 Trouble ShootingQ2.1.1 Help! XEmacs just crashed on me!New with 19.14, you may use the command M-x recover-session after a crash to pick up where you left off.
Now, XEmacs is not perfect, and there may occasionally be times, or particular sequences of actions, that cause it to crash. If you can come up with a reproducible way of doing this (or even if you have a pretty good memory of exactly what you were doing at the time), the maintainers would be very interested in knowing about it. Post a message to comp.emacs.xemacs or send mail to crashes@xemacs.org. Please note that the crashes address is exclusively for crash reports.
If at all possible, include a stack backtrace of the core dump that was produced. This shows where exactly things went wrong, and makes it much easier to diagnose problems. To do this, you need to locate the core file (it's called core, and is usually sitting in the directory that you started XEmacs from, or your home directory if that other directory was not writable). Then, go to that directory and execute a command like
gdb `which xemacs` coreand then issue the command where to get the stack backtrace. You might have to use dbx or some similar debugger in place of gdb. If you don't have any such debugger available, complain to your system administrator.
It's possible that a core file didn't get produced, in which case you're out of luck. Go complain to your system administrator and tell him not to disable core files by default. Also see Q2.1.15 for tips and techniques for dealing with a debugger.
When making a problem report make sure that:
Q2.1.2 Cryptic Minibuffer messagesIf you can't figure out what's going on, select Options/General Options/Debug on Error from the Menubar and then try and make the error happen again. This will give you a backtrace that may be enlightening. If not, try reading through this FAQ; if that fails, you could try posting to comp.emacs.xemacs (making sure to include the backtrace) and someone may be able to help. If you can identify which Emacs lisp source file the error is coming from you can get a more detailed stack backtrace by doing the following:
Depending on the version of XEmacs, you may either select Edit->Show
Messages (19.13 and earlier) or Help->Recent Keystrokes/Messages (19.14
and later) from the menubar to see the most recent messages. This command
is bound to C-h l by default.
Q2.1.3 Translation Table Syntax messages at StartupThere are two causes of this problem. The first usually only strikes people using the prebuilt binaries. The culprit in both cases is the file XKeysymDB
<xemacs_root_directory>/lib/xemacs-19.15/etc/XKeysymDB
Q2.1.4 Startup warnings about deducing proper fonts?This is highly dependent on your installation, but try with the following font as your base font for XEmacs and see what it does:
-adobe-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1More precisely, do the following in your resource file:
Emacs.default.attributeFont: -adobe-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1If you just don't want to see the *Warnings* buffer at startup time, you can set this:
(setq display-warning-minimum-level 'error)The buffer still exists; it just isn't in your face.
Q2.1.5 XEmacs cannot connect to my X Terminal
Try setting the DISPLAY variable using the numeric IP address of the
host you are running XEmacs from.
Q2.1.6 XEmacs just locked up my Linux X serverThere have been several reports of the X server locking up under Linux. In all reported cases removing speedo and scaled fonts from the font path corrected the problem. This can be done with the command 'xset'.
It is possible that using a font server may also solve the problem.
Q2.1.7 HP Alt key as MetaPut the following line into a file and load it with xmodmap(1) before starting XEmacs:
remove Mod1 = Mode_switch
Q2.1.8 got (wrong-type-argument color-instance-p nil) and I don't know why!I am trying to run xemacs 19.13 under X11R4. Whenever I move the mouse I get the following error. Has anyone seen anything like this? This doesn't occur on X11R5.
Signalling: (error "got (wrong-type-argument color-instance-p nil) and I don't know why!")
dinos <map01kd@gold.ac.uk> writes:
I think this is due to undefined resources; You need to define color backgrounds and foregrounds into your .../app-defaults/Emacs like:
*Foreground: Black ;everything will be of black on grey95, *Background: Grey95 ;unless otherwise specified. *cursorColor: Red3 ;red3 cursor with grey95 border. *pointerColor: Red3 ;red3 pointer with grey95 border.
Natalie Kershaw adds:
What fixed the problem was adding some more colors to the X color database (copying the X11R5 colors over), and also defining the following resources:
xemacs*cursorColor black xemacs*pointerColor blackWith the new colours installed the problem still occurs if the above resources are not defined.
If the new colours are not present then an additional error occurs on XEmacs startup, which says Color Red3 not defined.
Q2.1.9 XEmacs causes my OpenWindows 3.0 server to crashQ2.1.10 Warnings from incorrect key modifiersIf you're having troubles with HP/UX it is because HP/UX defines the modifiers wrong in X. Here is a shell script to fix the problem; be sure that it is run after VUE configures the X server.
#! /bin/sh xmodmap 2> /dev/null - << EOF keysym Alt_L = Meta_L keysym Alt_R = Meta_R EOF xmodmap - << EOF clear mod1 keysym Mode_switch = NoSymbol add mod1 = Meta_L keysym Meta_R = Mode_switch add mod2 = Mode_switch EOF
Q2.1.11 This question intentionally left blankObsolete question, left blank to avoid renumbering.
Q2.1.12 Problems with Regular Expressions on DEC OSF1I have xemacs 19.13 running on an alpha running OSF1 V3.2 148 and ispell would not run because it claimed the version number was incorrect although it was indeed OK. I traced the problem to the regular expression handler.
Douglas Kosovic <douglask@dstc.edu.au> writes:
Actually it's a DEC cc optimisation bug that screws up the regexp handling in XEmacs.
Rebuilding using the -migrate switch for DEC cc (which uses a different sort of optimisation) works fine.
See xemacs-19_13-dunix-3_2c.patch at the following URL on how to build with the -migrate flag:
<http://www-digital.cern.ch/carney/emacs/emacs.html>.
NOTE: There have been a variety of other problems reported that are fixed in this fashion.
Q2.1.13 HP/UX 10.10 and create_process failure
With XEmacs 19.13 and HP/UX 10.10, anything that relies on the
reate_process function fails. This breaks a lot of things
(shell-mode, compile, ange-ftp, to name a few).
Phil Johnson <johnson@dtc.hp.com> writes:
This is a problem specific to HP-UX 10.10. It only occurs when XEmacs is compiled for shared libraries (the default), so you can work around it by compiling a statically-linked binary (run configure with --dynamic=no).
I'm not sure whether the problem is with a particular shared library or if it's a kernel problem which crept into 10.10.
Richard Cognot <cognot@ensg.u-nancy.fr> writes:
I had a few problems with 10.10. Apparently, some of them were solved by forcing a static link of libc (manually).
Q2.1.14 C-g doesn't work for me. Is it broken?C-g does work for most people in most circumstances. If it doesn't, there are only two explanations:
inhibit-quit to
t. Ctrl-Shift-G should still work, I think.
To test #2, try executing
(while t)from the *scratch* buffer. If C-g doesn't interrupt, then you're seeing #2.
Morten Welinder <terra@diku.dk> writes:
On some (but not all) machines a hung XEmacs can be revived by
kill -FPE <pid>. This is a hack, of course, not a solution. This technique works on a Sun4 running 4.1.3_U1. To see if it works for you, start another XEmacs and test with that first. If you get a core dump the method doesn't work and if you get
Arithmetic errorthen it does.
Q2.1.15 How to Debug an XEmacs problem with a debuggerIf XEmacs does crash on you, one of the most productive things you can do to help get the bug fixed is to poke around a bit with the debugger. Here are some hints:
--debug=yes,
--error-checking=all, and
--dynamic=no. This will make your XEmacs run somewhat slower but make it a lot more likely to catch the problem earlier (closer to its source), and a lot easier to determine what's going on with a debugger.
assert_failed().
signal_1() -- this is declared static in eval.c.
call debug_print (OBJECT)where OBJECT is whatever you want to decode (it can be a variable, a function call, etc.). This will print out a readable representation on the TTY from which the xemacs process was invoked.
call debug_backtrace ()
If you're using DBX, you may be able to get further help from Martin Buchholz, the engineer at Sun who works on XEmacs. Write to him at <Martin.Buchholz@sun.com>.
Curtiss <1CMC3466@ibm.mtsac.edu> suggests upgrading to ld.so version 1.8 if dynamic linking and debugging is a problem on Linux.
Here's some more info about using gdbinit:
Different version of gdbinit are provided for different platforms. One of these should be installed as .gdbinit in your home directory. If you're using XEmacs 19.14 or better, you should install the default gdbinit in the src/ directory if you have GDB 4.14 or better. With GDB 4.13 or earlier, install "gdbinit.pre-4.14"; however, this is noticeably harder to use. If you're on a machine that uses a union type for Lisp_Objects (only the DEC Alpha, I think), you'll have to use gdbinit.union, which is of the pre-4.14 variety but should be easily upgradable.
With XEmacs 19.13 and earlier, only one gdbinit is provided (I think); it's of the pre-4.14 variety and of the union-type variety. (Many more machines used the union type under 19.13).
With the GDB 4.14+ gdbinit, you can print out a Lisp_Object using
p1 OBJECT
(which calls debug_print(), and hence only works if you have
a running process) or frob OBJECT (which works even on core
dumps, and does its own decoding of the object, but its output isn't
always so convenient).
With the pre-GDB 4.14 gdbinit, you have to do these steps:
print OBJECT xtype <then type "xcons" or "xstring" or whatever, depending on the type>If the object is a record type, you'll probably have to the following steps:
print OBJECT xtype xrecord <remember what type is printed> print OBJECT <then type "xbuffer" or "xsymbol" or whatever>Of course, if you know in advance what type the object is of, you can omit all but the last two steps.
Q2.1.16 XEmacs crashes in strcat on HP/UX 10Problem Report: 5003302299 Status: Open System/Model: 9000/700 Product Name: HPUX S800 10.0X Product Vers: 9245XB.10.00 Description: strcat(3C) may read beyond end of source string, can cause SIGSEGV *** PROBLEM TEXT *** strcat(3C) may read beyond the source string onto an unmapped page, causing a segmentation violation.
Q2.1.17 Marker does not point anywhere1. A problem with line-number-mode in XEmacs 19.14 affected a large number of other packages. If you see this error message, turn off line-number-mode.
2. A problem with some early versions of Gnus 5.4 caused this error. Upgrade your Gnus.
Q2.1.18 19.14 hangs on HP/UX 10.10For the record, compiling on hpux 10.10 leads to a hang in Gnus when compiled with optimization on.
I've just discovered that my hpux 10.01 binary was working less well
than expected. In fact, on a 10.10 system, (while t) was not
interupted by C-g. I defined BROKEN_SIGIO and
recompiled on 10.10, and... the hang is now gone.
As far as configure goes, this will be a bit tricky: BROKEN_SIGIO is needed on 10.10, but not on 10.01: if I run my 10.01 binary on a 10.01 machine, without BROKEN_SIGIO being defined, C-g works as expected.
Richard Cognot <cognot@ensg.u-nancy.fr> adds:
Apparently somebody has found the reason why there is this
poll: interrupted...message for each event. For some reason, libcurses reimplements a
select() system call,
in a highly broken fashion.
The fix is to add a -lc to the link line before the
-lxcurses. XEmacs will then use the right version of select().
Alain Fauconnet <af@biomath.jussieu.fr> writes:
The real solution is to not link -lcurses in! I just changed -lcurses to -ltermcap in the Makefile and it fixed :
poll: interrupted system callmessage
Q2.1.19 XEmacs does not follow the local timezone(set-time-zone-rule "MET")to your .emacs or the site-start.el file if you can. Replace MET with your local timezone.
Q2.1.20 Symbol's function definition is void: hkey-help-show(require 'hmouse-drv)where you load hyperbole and the problem should go away.
Q2.1.21 Every so often the XEmacs frame freezesQ2.1.22 XEmacs seems to take a really long time to do some things Two things you can do:
When you see it going mad like this, you might want to use gdb from an 'xterm' to attach to the running process and get a stack trace. To do this just run:
gdb /path/to/xemacs/xemacs ####
Where #### is the process id of your xemacs, instead of specifying
the core. When gdb attaches, the xemacs will stop [1] and you can
type `where' in gdb to get a stack trace as usual. To get things
moving again, you can just type `quit' in gdb. It'll tell you the
program is running and ask if you want to quit anyways. Say 'y'
and it'll quit and have your emacs continue from where it was at.
Turn on debug-on-quit early on. When you think things are going slow hit C-g and it may pop you in the debugger so you can see what routine is running. Press `c' to get going again.
debug-on-quit doesn't work if something's turned on inhibit-quit or in some other strange cases.
Q2.1.23 Movemail on Linux does not work for XEmacs 19.15 and laterSteven L Baur <steve@miranova.com> writes:
Movemail on Linux used to default to using flock file locking. With 19.15 and 20.0 it now defaults to using .lock file locking. If this is not appropriate for your system, edit src/s/linux.h and uncomment the line that reads:
`#define MAIL_USE_FLOCK'
This FAQ is Copyright © 1998 by various people and edited by Andreas Kaempf. Please send comments, and suggestions to Andreas Kaempf <andreas@sccon.com>.