Ceci est la deuxième partie de la Foire Aux Questions sur XEmacs. Cette section est consacrée à l'installation, à la maintenance et à la gestion des erreurs.
Le fichier `INSTALL' indique qu'il faut jusqu'à 108 Mo d'espace temporairement disponible pendant l'installation ! Comment puis-je simplement l'essayer ?
XEmacs peut être lancé sitôt compilé, sans installation ni copie des répertoires Lisp et sans devoir spécifier une option particulière de compilation. C'est la copie des répertoires Lisp qui demande tant de place. XEmacs est largement écrit en Lisp.
Une bonne méthode consiste à créer un alias shell pour XEmacs :
alias xemacs=/i/xemacs-20.2/src/xemacs
(À la place de `/i/xemacs-20.2', utilisez évidemment le répertoire où vous avez placé l'arborescence source).
Ceci vous permettra de lancer XEmacs en évitant de tout copier.
Bien que ce qui suit ait été écrit pour XEmacs 19.13, la majeure partie de ce qui est dit est encore vraie.
Steve Baur <steve@altair.xemacs.org> écrit :
Les 45 Mo nécessaires aux répertoires d'installation peuvent être considérablement réduit si on le désire. Compressez tous les fichiers .el. Ôtez tous les paquetages que vous ne voudrez jamais utiliser (ou ceux qui sont obsolètes comme mailcrypt et Gnus 4 avec 19.13). Supprimez les manuels TexInfo, le répertoire info (et n'utilisez que des versions imprimées du manuel). Ôtez la plus gros de ce qui se trouve sous `etc'. Supprimez ou compressez tout le code source source C. Je ne conseille pas ici de procéder ainsi mais indique simplement comment réduire l'espace disque nécessaire si on le désire.
Examinons maintenant l'espace occupé :
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.13Vous devez garder ceux-ci. XEmacs n'est pas relié par défaut lors de l'installation et vous devrez le faire si vous le voulez. Cela vous permettra d'économiser 5 Mo ici.
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/gnusCeux-ci sont les répertoires de prise en charge des différents paquetages. Généralement, ils correspondent à un répertoire qui se trouve sous ./xemacs-19.13/lib/xemacs-19.13/lisp/. Si vous n'avez pas besoin d'un paquetage, vous pouvez supprimer ou compresser le répertoire correspondant.
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/lispTout ceci est du code source Emacs Lisp et du code compilé. Vous pouvez compresser sans problème tout ce qui s'appelle *.el et supprimer les paquetages que vous n'utilisez pas. Il ne se passera rien si vous détruisez un paquetage que vous n'utilisez pas. Évidemment, vous devez être sûr de ne pas l'utiliser, commencez donc avec les précautions d'usage.
Des candidats possibles à la suppression sont w3 (de nouvelles versions existent, ou bien vous utilisez Lynx ou Netscape comme navigateur Web), games, hyperbole, mh-e, hm--html-menus (il existe de meilleurs paquetages), vm, viper, oobr, gnus (il existe des versions plus récentes), etc. Demandez-vous Aurais-je besoin de ce paquetage un jour ? : si la réponse est non, il est candidat à la suppression.
Compressez d'abord tous les fichiers .el, puis commencez à compresser les fichiers .elc d'un paquetage probablement inutile. Lancez alors XEmacs et faites ce que vous faites habituellement. Si rien de fâcheux ne se passe, détruisez le répertoire et appliquez cette procédure au paquetage inutile suivant. Ne détruisez pas les répertoires inconsidérément. Il est pratique de disposer de sauvegardes dans le cas où vous auriez été trop destructeur.
`prim', `modes', `packages' et `utils' sont quatre répertoires que vous ne devez surtout pas détruire, bien que certains paquetages puissent y être supprimés si vous ne les utilisez pas.
1972 /usr/local/lib/xemacs-19.13/infoCe sont les sources texinfo en ligne. Vous pouvez les compresser ou les supprimer. Dans les deux cas, C-h i (info mode) ne fonctionnera plus.
20778 /usr/local/lib/xemacs-19.13Les 20 Mo occupés représentent moins de la moitié de la distribution complète, et peuvent être obtenus sans supprimer un seul fichier.
giacomo boffi <boffi@hp735.stru.polimi.it> indique cette procédure :
Substituez `/usr/local/lib/' avec le chemin de la racine de l'arborescence de XEmacs, puis utilisez ce 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 # compresse (supprime) uniquement (UNIQUEMENT) les sources qui ont # un fichier compilé correspondant -- ne touche pas (PAS) aux # autres sources if test -f ${f}c ; then gzip -v9 $f >> $r/cmpr ; fi done cd .. fi done du -s .Une étape supplémentaire consisterait à mettre `rm -f' à la place de `gzip -v9', mais il faut être désespéré pour supprimer les sources (rappelez-vous que XEmacs peut accéder aux fichiers compressés de façon transparente).
Un bon mega-octet peut aussi être facilement gagné à partir du répertoire $r/../etc. Par exemple, les fichiers termcap, certains 0+NEWS, d'autres encore...
XEmacs 20.5 découpera la hiérarchie Lisp et permettra de choisir exactement le code support à installer.
Quelle est la meilleure façon de compiler XEmacs avec le système netaudio lorsque je l'ai installé à un emplacement bizarre et que je ne suis pas root. De plus, il n'est rien dit sur la compilation avec l'audioserver dans les README.
Vous n'avez besoin que d'ajouter quelques options sur la ligne de commande de configure. Pour lui indiquer de compiler avec la gestion netaudio : `--with-sound=both' (ou `--with-sound=nas' si vous ne souhaitez pas la gestion native du son pour une raison ou une autre). Pour lui indiquer où trouver les fichiers en-têtes et les bibliothèques netaudio :
--site-libraries=WHATEVER --site-includes=WHATEVER
Puis (croisons les doigts), il devrait se compiler et utilisera netaudio si vous disposez d'un serveur en état de marche correspondant au serveur X. Le serveur netaudio doit être présent lorsque XEmacs est lancé. Si le serveur netaudio est supprimé et qu'un autre est lancé, XEmacs devrait s'en tirer (en croisant les doigts car la gestion des erreurs de netaudio n'est pas parfaite).
De plus, netaudio a changé de nom car il y avait une confusion avec autre chose. Si vous voyez des références à NAS ou Network Audio System, c'est la même chose. Il peut aussi être obtenu à <URL:ftp.x.org:/contrib/audio/nas/>.
Avec Linux 1.3.98, termcap 2.0.8 et la ncurses livrée avec la libc 5.2.18, XEmacs 20.0b20 ne peut ouvrir un périphérique tty :
src/xemacs -nw -q Initialization error: Terminal type `xterm' undefined (or can't access database?)
Ben Wing <ben@666.com> écrit :
Votre configuration ncurses est incorrecte. Votre `/usr/lib/terminfo' est un mauvais pointeur, peut-être vers un CD-ROM qui n'est pas inséré.
Non. Le nom XEmacs est malheureux dans le sens où il n'est pas une version uniquement X-Window d'Emacs. À partir de la versions 19.14, XEmacs sait gérer complètement les couleurs sur un terminal couleur.
Il y a eu de nombreux rapports de crashs dus à des compilateurs ayant des optimisateurs buggés. Lisez le fichier `PROBLEMS' livré avec XEmacs pour voir ce qu'il dit à propos de votre plate-forme.
J'ai x-faces, jpeg, xpm, etc. tous à des emplacements différents. J'ai essayé plusieurs --site-libraries, séparés par des espaces, des virgules, mais sans résultat.
--site-libraries='/path/one /path/two /path/etc'
Vous utilisez la distribution Linux/ELF d'XEmacs 19.14, et vos bibliothèques ELF ne sont pas à jour. Vous pouvez faire les choses suivantes :
Hrvoje Niksic <hniksic@srce.hr> ecrit :
Pourquoi ne pas utiliser une ligne Perl pour le No. 2 ?
perl -pi -e 's/_h_errno\0/h_errno\0\0/g' /usr/local/bin/xemacs-19.14NB : Vous devez patcher `/usr/local/bin/xemacs-19.14', et non `xemacs' car `xemacs' est un lien vers `xemacs-19.14' ; l'option `-i' de Perl provoquera des effets de bords indésirables si elle est appliqué à un lien symbolique.
Steve L. Baur <steve@miranova.com> écrit :
Si vous construisez en utilisant une libc-5.4 récente (suffisamment pour avoir provoqué des problèmes plus tôt dans le cycle des tests beta) et que vous exécutez avec une version plus ancienne de libc, vous obtiendrez un
$ xemacs xemacs: can't resolve symbol '__malloc_hook' zsh: 7942 segmentation fault (core dumped) xemacs(Exemple de binaire compilé avec une libc-5.4.23 et exécuté avec une libc-5.4.16).
La solution est une mise à jour vers la libc-5.4.23 au moins. Snif.
Toutes les bibliothèques externes utilisées par XEmacs peuvent être obtenues sur le site FTP de XEmacs <URL:ftp://ftp.xemacs.org/pub/aux/>.
Les emplacements canoniques (au moment de cette rédaction) sont :
Ce n'est pas nécessairement grave. Si vous avez GNU sed 3.0, revenez à sa version 2.05. D'après le `README' de prep.ai.mit.edu :
sed 3.0 a été retiré de la distribution. Il comportait des modifications importantes qui semblaient être des améliorations mais qui contenaient trop de bugs pouvant poser des problèmes dans certains cas.
Tom Lord ne pourra pas corriger les bugs avant le mois de mai. En attendant, nous avons décidé de retirer sed 3.0 de la distribution et de revenir à sed 2.05 comme version recommandée.
On a aussi pu observer que le test vfork provoquait un core dump sur Solaris.
Cela provient d'un problème ancien avec SunOS et du fait que les systèmes SunOS déjà produits n'intègrent pas le code du resolveur DNS dans la libc.
Christopher Davis <ckd@loiosh.kei.com> écrit :
C'est normal. Comme Sun pensait que tout le monde utiliserait NIS pour faire cette recherche (ce truc de DNS n'était apparemment qu'une passade, non ?), les systèmes SunOS 4.x existants n'ont pas de recherche de noms basé sur DNS dans la libc.
C'est aussi pour cette raison que Netscape fournit deux binaires pour SunOS 4.1.x.
La meilleure solution est de le compiler vous-même ; le script configure vérifiera si vous avez intégré DNS dans la libc partagée et fera ensuite le lien avec le code du résolveur DNS de la bibliothèque.
Richard Cognot <cognot@fronsac.ensg.u-nancy.fr> écrit :
À cause de la façon dont XEmacs (et d'autres Emacs, pour autant que je sache) est construit. L'édition de liens vous donne un emacs réduit à sa plus simple expression (temacs). Celui-ci est alors lancé et charge plusieurs fichiers lisp. Le résultat est alors vidé dans un nouvel exécutable, appelé xemacs, qui contiendra toutes les fonctions lisp et données pré-chargées.
Pendant ce vidage, l'exécutable (code + données + symboles) est écrit sur le disque en utilisant une fonction unexec() spéciale. Celle-ci est évidemment fortement dépendante du système. Sur certains systèmes, cela conduit à un exécutable qui, bien que valide, ne peut être stripé sans dommages. Si j'ai bonne mémoire, c'est notamment le cas avec les binaires AIX. Sous d'autres architectures, cela peut fonctionner.
La bonne façon de striper le binaire emacs est de striper temacs avant la création de xemacs. Cela fonctionnera toujours, bien que vous ne puissiez le faire que si vous faites une installation à partir des sources (car temacs ne fait `pas' partie des kits binaires).
Nat Makarévitch <nat@nataa.fr.eu.org> écrit :
Voici l'astuce :
- [ ./configure; make ]
- rm src/xemacs
- strip src/temacs
- make
- cp src/xemacs /usr/local/bin/xemacs
- cp lib-src/DOC-19.15-XEmacs /usr/local/lib/xemacs-19.15/i586-unknown-linuxaout
Il y a des difficultés connues lors de l'édition de lien avec GNU ld sur Solaris. Un message d'erreur typique peut ressembler à ça :
unexec(): dlopen(../dynodump/dynodump.so): ld.so.1: ./temacs: fatal: relocation error: symbol not found: main: referenced in ../dynodump/dynodump.so
Martin Buchholz <mrb@eng.sun.com> écrit :
Vous devez préciser `-fno-gnu-linker' comme option à ld. Les versions futures de XEmacs essaieront de le faire automatiquement.
Problème lors de la construction de XEmacs-19.16 sur hpux 9 :
Richard Cognot <cognot@ensg.u-nancy.fr> écrit :
Le make sur hpux échoue après l'édition de liens de temacs, avec le message :
"make: don't know how to make .y."Solution : C'est un problème dû à la version 70.X du make de HP. Utilisez GNU make, ou installez PHCO_6552, qui amènera make à la version 72.24.1.17.
Avant tout, pas de panique ! À chaque fois que XEmacs se plante, il
essaie de sauvegarder automatiquement tous vos fichiers
avant de mourir (mais ne pourra le faire si votre machine a une coupure
d'alimentation ou si vous tuez son processus avec un kill
-9). La prochaine fois que vous essaierez d'éditer ces fichiers, un
message vous informera qu'un fichier « auto-save » plus récent
existe. Vous pouvez alors utiliser M-x recover-file pour récupérer
la version sauvegardée du fichier.
À partir de la version 19.14, vous pouvez utiliser la commande M-x recover-session après un crash pour revenir au point ou vous étiez avant celui-ci.
Cependant, XEmacs n'est pas parfait et il peut arriver parfois des moments, ou des suites particulières d'action, qui le font planter. Si vous arrivez à reproduire la façon de le faire (ou si vous vous rappelez bien ce que vous faisiez à ce moment précis), les mainteneurs seront très intéressés par votre mésaventure. Publiez un article dans comp.emacs.xemacs ou envoyez un message à <crashes@xemacs.org>. Notez bien que l'adresse `crashes' est exclusivement réservée au rapports de crashs.
Si possible, ajoutez une trace du core dump qui a été produit. Cela indique exactement l'endroit où les choses ont mal tourné et facilite beaucoup le diagnostic des problèmes. Pour ce faire, localisez le fichier `core', qui se trouve habituellement dans le répertoire d'où vous avez lancé XEmacs ou dans votre répertoire personnel si le précédent n'est pas autorisé en écriture. Puis, dans ce répertoire, exécutez la commande :
gdb `which xemacs` core
et ensuite la commande `where' pour obtenir la trace de la pile
d'exécution. Vous pouvez utiliser dbx ou un autre débugger à la
place de gdb. Si vous ne disposez d'aucun débugger,
plaignez-vous auprès de votre administrateur système.
Il est possible qu'un fichier core ne soit pas produit, auquel cas vous n'avez pas de chance. Allez vous plaindre à votre administrateur système et dites-lui de ne pas désactiver par défaut l'engendrement de fichiers core. Voir aussi See section Comment débugger un problème de XEmacs avec un débugger ? pour des conseils et des techniques d'utilisation d'un débugger.
Lorsque vous faites un rapport de problème, assurez-vous de :
Lorsque j'essaie une option ou un paquetage particuliers, j'obtiens une erreur incompréhensible dans le mini-tampon.
Si vous ne pouvez deviner ce dont il s'agit, choisissez Options/General Options/Debug on Error à partir du menu et réessayez de provoquer l'erreur. Cela vous donnera une trace qui peut vous éclairer. Sinon, parcourez cette FAQ ; si cela ne donne rien, essayer de poster dans comp.emacs.xemacs (en ajoutant la trace obtenue) et quelqu'un sera peut-être en mesure de vous aider. Si vous pouvez identifier le fichier source Emacs lisp d'où vient l'erreur, vous pourrez obtenir une trace plus détaillée en faisant ce qui suit :
Selon la version de XEmacs, vous pouvez sélectionner soit
Edit->Show Messages (19.13 et précédentes) soit
Help->Recent Keystrokes/Messages (19.14 et plus récentes) à
partir du menu pour voir les plus récents messages. Cette commande est,
par défaut, liée à C-h l.
J'obtiens des tonnes de messages d'erreur de syntaxe de la table de traduction au moment du démarrage. Comment puis-je m'en débarasser ?
Il y a deux causes à ce problème. Habituellement, la première concerne uniquement les personnes qui utilisent les binaires précompilés. Dans les deux cas, le coupable est le fichier `XKeysymDB'.
Comment puis-je éviter les avertissements du démarrage à propos de la déduction des fontes correctes ?
Cela dépend beaucoup de votre installation, mais essayez la fonte suivante comme fonte de base pour XEmacs et voyez ce que cela donne :
-adobe-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1
Plus précisément, mettez la ligne suivante dans votre fichier de ressources :
Emacs.default.attributeFont: -adobe-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1
Si vous ne voulez simplement pas voir le tampon `*Warnings*' au démarrage, vous pouvez faire ça :
(setq display-warning-minimum-level 'error)
Le tampon existe encore, mais il ne vous apparait pas.
À l'aide ! Je ne peux pas arriver à faire afficher XEmacs sur mon terminal X Envizex !
Essayez de configurer la variable DISPLAY en utilisant l'adresse IP numérique de la machine à partir de laquelle vous lancez XEmacs.
Il y a eu plusieurs rapports de bloquage du serveur X sous Linux. Dans
tous les cas, le fait de supprimer les fontes speedo et scaled du chemin
des fontes a corrigé le problème. Ceci peut être fait avec la commande
xset.
Il est possible que l'utilisation d'un serveur de fontes puisse aussi corriger ce problème.
Comment faire reconnaitre à XEmacs la touche Alt de ma station de travail HP comme touche Meta ?
Placez la ligne suivante dans un fichier et chargez-le avec xmodmap(1) avant de lancer XEmacs :
remove Mod1 = Mode_switch
Natalie Kershaw <nataliek@rd.scitec.com.au> écrit :
J'essaie de lancer XEmacs 19.13 sous X11R4. À chaque fois que je déplace la souris, j'obtiens l'erreur suivante. Quelqu'un a-t-il déjà vu ça ? Cela n'arrive pas sous X11R5.
Cela met : (error "got (wrong-type-argument color-instance-p nil) and I don't know why !")
dinos <map01kd@gold.ac.uk> écrit :
Je pense que cela est du à des ressources non définies. Vous devez définir les couleurs d'arrière et de premier plans dans votre fichier `.../app-defaults/Emacs' like:
*Foreground: Black ;tout sera noir sur grey95. *Background: Grey95 ;à moins qu'autre chose ne soit précisé. *cursorColor: Red3 ;curseur red3 avec un contour grey95. *pointerColor: Red3 ;pointeur red3 avec un contour grey95.
Natalie Kershaw ajoute :
Ce qui a corrigé le problème a été d'ajouter des couleurs supplémentaires à la base de données des couleurs X (en recopiant celle de X11R5) et aussi de définir les ressources suivantes :
xemacs*cursorColor: black xemacs*pointerColor: blackAvec les nouvelles couleurs installées, le problème persiste si les ressources ci-dessus ne sont pas définies.
Si les nouvelles couleurs ne sont pas présentes, une erreur supplémentaire se produit au démarrage de XEmacs, indiquant `Couleur Red3' non définie.
Le serveur OpenWindows 3.0 est incroyablement buggé. La meilleure solution consiste à le remplacer par un serveur de la distribution générique X11 du MIT. Vous pouvez aussi essayer de désactiver des parties de votre `.emacs', comme l'utilisation des pixmaps d'arrière plan.
Les informations suivantes viennent du fichier `PROBLEMS' qui est livré avec XEmacs.
Si vous avez des problèmes avec HP/UX, c'est parce qu'HP/UX définit mal les modificateurs sous X. Voici un script shell pour régler le problème ; assurez-vous de le lancer après que VUE ait configuré le serveur X.
#! /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
Question obsolète, conservée vide pour éviter une renumérotation.
J'ai XEmacs 19.13 qui s'exécute sur un alpha tournant sous OSF1 V3.2 148 et ispell ne veut pas se lancer car il se plaint que le numéro de version est incorrect, bien qu'il soit OK. J'ai repéré l'origine du problème dans le gestionnaire des expressions rationnelles.
Douglas Kosovic <douglask@dstc.edu.au> écrit :
C'est un bug de l'optimisation de DEC cc qui perturbe la gestion des expressions rationnelles de XEmacs.
Reconstruire en utilisant l'option `-migrate' de DEC cc (qui utilise un autre type d'optimisation).
Voir `xemacs-19_13-dunix-3_2c.patch' à l'URL suivante pour la construction avec l'option `-migrate' :
<URL:http://www-digital.cern.ch/carney/emacs/emacs.html>
REMARQUE : Il y a eu beaucoup d'autres problèmes rapportés qui ont été réglés de cette façon.
create_processDave Carrigan <Dave.Carrigan@ipl.ca> écrit :
Avec XEmacs 19.13 et HP/UX 10.10, tout ce qui utilise la fonction
create_processéchoue. Cela empêche beaucoup de choses (shell-mode, compile, ange-ftp, pour n'en citer que quelques uns).
Phil Johnson <johnson@dtc.hp.com> écrit :
C'est un problème spécifique à HP-UX 10.10. Il n'intervient que lorsque XEmacs est compilé pour utiliser les bibliothèques partagées (ce qui est le choix par défaut), vous pouvez donc contourner ce problème en compilant un binaire lié statiquement (lancez configure avec l'option `--dynamic=no').
Je ne sais pas si le problème vient d'une bibliothèque partagée particulière ou s'il s'agit d'un problème du noyau en 10.10.
Richard Cognot <cognot@ensg.u-nancy.fr> écrit :
J'avais quelques problèmes avec 10.10. Apparemment, certains d'entre eux ont été résolus en forçant un lien statique de libc (manuellement).
Ben Wing <ben@666.com> écrit :
C-g fonctionne dans la majeure partie des cas. Sinon, il n'y a que deux explications :
- Le code est entouré par un lien de
inhibit-quitàt. Ctrl-Shift-G devrait quand même fonctionner, je crois.- SIGIO est brisé sur votre système, mais BROKEN_SIGIO n'est pas défini.
Pour tester le n°2, essayez d'exécuter
(while t)à partir du tampon `*scratch*'. Si C-g ne l'interrompt pas, alors vous êtes dans la situation n°2.
Morten Welinder <terra@diku.dk> écrit :
Sur certaines (mais pas toutes) machines, un XEmacs planté peut être ravivé par
kill -FPE <pid>. C'est un hack, bien sûr, pas une solution. Cette technique fonctionne sur une Sun4 sous 4.1.3_U1. Pour vérifier que cela fonctionne chez vous, lancez un autre XEmacs et testez d'abord avec lui. Si vous obtenez un core dump, la méthode ne fonctionne pas et si vous obtenez une `Arithmetic error' alors elle fonctionne.
Ben Wing <ben@666.com> écrit :
Si XEmacs se plante, une des choses les plus productives que vous pouvez faire pour corriger le bug est de travailler un peu avec le débugger. Voici quelques conseils :
- D'abord, si le crash se reproduit toujours, il est très fortement conseillé de recompiler votre XEmacs avec les symboles de débuggage, sans optimisation et avec les options `--debug=yes', `--error-checking=all' et `--dynamic=no' de configure. Cela fera que votre XEmacs tournera un peu plus lentement mais le rendra beaucoup plus apte à détecter plus tôt les problèmes et il sera beaucoup plus facile de déterminer ce qui se passe qu'avec un débugger.
- Si vous pouvez lancer XEmacs sous un débugger et reproduire le crash (s'il y a un inconvénient à faire cela car XEmacs tourne déjà ou tourne en mode batch comme partie d'un lot de scripts, essayez d'attacher le processus existant à votre débugger ; la plupart des débuggers permettent de faire cela en substituant l'ID du processus pour le fichier core lorsque vous invoquez le débugger à partir de la ligne de commande ou en utilisant la commande
attachou quelque chose de similaire), voici ce que vous pouvez faire :- Si XEmacs trouve une erreur d'assertion, placez un point d'arrêt sur
assert_failed().- Si XEmacs trouve une erreur Lisp bizarre qui provoque le crash (par exemple, au démarrage), placez un point d'arrêt sur
signal_1()--- elle est déclarée comme static dans eval.c.- Vous verrez probablement beaucoup de variables contenant des objets de type
Lisp_Object. Elles sont exactement ce qu'elles semblent être : des références à des objets Lisp. Les afficher avec le débugger ne serait pas trop utile -- vous ne verriez qu'un nombre. Pour les décoder, faites ceci :call debug_print (OBJECT)où OBJECT est ce que vous voulez décoder (cela peut etre une variable, un appel de fonction, etc.). Cela affichera une représentation lisible sur le terminal à partir duquel le processus XEmacs a été invoqué.- Si vous voulez une trace montrant la pile d'appel Lisp, faites ceci :
call debug_backtrace ()- Utiliser
debug_printetdebug_backtraceprésente deux inconvénients - cela ne peut être fait que sur un processus XEmacs en cours d'exécution et ça n'affiche pas la structure C interne d'un objet Lisp. Même si tout ce que vous obtenez est un core dump, tout n'est pas perdu. Si vous utilisezgdb, il y a des macros dans le fichier `gdbinit' du répertoire `src' de la distribution XEmacs qui facilite le décodage des objets Lisp. Copiez ce fichier dans`~/.gdbinit', ousourcez-le en~/.gdbinit, puis utilisez les macros qui y sont définies. En particulier, la macropobjimprime la représentation C interne d'un objet Lisp. Cela fonctionnera avec un fichier core ou un exécutable non lancé. Les aliasldpetlbtsont fournis pour appeler correctementdebug_printetdebug_backtrace. Si vous utilisez le débuggerdbxde Sun, il y a un fichiersrc/dbxrcéquivalent à copier ou à sourcer en~/.dbxrc.- Si vous utilisez un débugger pour avoir une trace de la pile C et que vous voyez des traces de pile avec certains des cadres les plus internes mélangés, cela peut être dû à l'édition de liens dynamique (ceci arrive surtout sous Linux). Essayez de reconfigurer avec `--dynamic=no'. Quelques fois aussi (toujours sous Linux), les traces des core dumps auront le cadre où le signal fatal est apparu en désordre ; si vous pouvez obtenir une trace de pile avec un débugger pendant qu'un XEmacs est en train de tourner, la trace de pile devrait être propre. Curtiss <1CMC3466@ibm.mtsac.edu> suggère de passer à la version 1.8 de ld.so si l'édition de liens dynamique et le débuggage est un problème sous Linux.
- Si vous utilisez un débugger pour obtenir une trace de pile C et que vous obtenez une trace complètement brouillée et buggée, c'est probablement du à l'une des raisons suivantes :
- Votre exécutable a été stripé. Mauvaise nouvelle. Dites à votre administrateur système de ne pas le faire -- cela ne fait rien sauf économiser un peu d'espace disque, mais cela complique beaucoup le débuggage.
- Votre pile a été endommagée. Débugger cela est difficile ; vous devez faire une recherche de type binaire jusqu'à l'endroit où le crash est apparu pour trouver la ligne exacte qui a provoqué le problème. Bien sûr, cela ne fonctionne que si le bug est bien reproductible.
- Si votre trace de pile a exactement un cadre, avec l'adresse 0x0, ceci peut simplement signifier que XEmacs a tenté d'exécuter du code à cette adresse, par exemple en sautant vers un pointeur de fonction null. Malheureusement, sous certaines circonstances,
gdbsous Linux ne sait pas comment obtenir une trace de pile (oui, c'est le troisième problème Linux que je mentionne. Je ne sais pas pourquoigdbest si buggé sous Linux, plaignez vous à ses auteurs ou à comp.os.linux.development.system). Vous devrez ici encore utiliser le processus de recherche décrit plus haut.- Si vous avez compilé 19.14 avec `--debug' (ou par défaut dans les dernières versions), vous obtiendrez une trace Lisp qui s'affichera lorsque XEmacs se plante : vous aurez donc quelque chose d'utile. Si vous êtes en 19.13, vous pouvez essayer de faire
call debug_backtrace()-- quelques fois cela fonctionne, même après qu'un signal fatal ait été reçu.
Voici encore quelques informations sur l'utilisation de gdbinit :
Les différentes versions de gdbinit sont fournies pour
différentes plates-formes. L'une d'elles doit être installée comme
`.gdbinit' dans votre répertoire personnel. Si vous utilisez XEmacs
19.14 ou supérieur, vous devrez installer le gdbinit par défaut
dans le répertoire `src/' si vous avez gdb 4.14 ou
supérieur. Avec gdb 4.13 ou inférieur, installez
`gdbinit.pre-4.14', mais cela est notablement plus difficile à
utiliser. Si vous êtes sur une machine qui utilise un type union pour
les Lisp_Objects (uniquement les DEC Alpha, je crois) vous devrez
utiliser gdbinit.union, qui est une variété pre-4.14 mais
qui peut être facilement mise à jour.
Avec XEmacs 19.13 et inférieur, seul un gdbinit est fourni (je
crois) ; c'est une variété pre-4.14 et de type union (beaucoup d'autres
machines utilisaient le type union sous 19.13).
Avec le gdbinit de gdb 4.14+, vuos pouvez afficher un
Lisp_Object avec p1 OBJECT (qui appelle debug_print(), et
ne fonctionne donc que si vous avez un processus qui tourne) ou
frob OBJECT (qui fonctionne même sur les core dumps et réalise
son propre décodage de l'objet, mais sa sortie n'est pas toujours très
pratique).
Avec les gdbinit pre-gdb 4.14, vous devez faire les étapes
suivantes :
print OBJECT xtype <puis tapez « xcons » ou « xstring » ou autre, selon le type>
Si l'objet est de type record, vous devrez probablement faire ce qui suit :
print OBJECT xtype xrecord <rappelez-vous du type affiché> print OBJECT <puis tapez « xbuffer » ou « xsymbol » ou autre>
Bien sûr, si vous savez à l'avance de quel type est l'objet, vous pouvez tout omettre sauf les deux dernières étapes.
strcat sur HP/UX 10>Dans la base de données des problèmes (de <URL:http://support.mayfield.hp.com/>):
Problem Report: 5003302299 Status: Open System/Model: 9000/700 Product Name: HPUX S800 10.0X Product Vers: 9245XB.10.00 Description: strcat(3C) peut lire au delà de la chaîne source et donc provoquer un SIGSEGV *** PROBLEM TEXT *** strcat(3C) peut lire au delà de la chaîne source sur une page non mappée, ce qui provoque une violation de segmentation.
Comme avec les autres erreurs, mettez debug-on-error à t
pour obtenir une trace lorsque l'erreur apparaît. Spécifiquement, deux
problèmes ont été rapportés (et corrigés).
Richard Cognot <cognot@ensg.u-nancy.fr> écrit :
Une compilation sur hpux 10.10 provoque un arrêt dans Gnus lorsqu'il a été compilé avec l'optimisation.
Je viens juste de découvrir que mon binaire hpux 10.01 fonctionnait moins bien que ce qu'on pourrait en attendre. En fait, sur un système 10.10,
(while t)n'était pas interrompu par C-g. J'ai définiBROKEN_SIGIOet recompilé sur 10.10, et... l'arrêt a disparu.C'est un peu rusé :
BROKEN_SIGIOest nécessaire sur 10.10, mais pas sur 10.01 : si j'exécute mon binaire 10.01 sur une machine 10.01, sans avoir définiBROKEN_SIGIO, C-g fonctionne normalement.Apparemment, quelqu'un a trouvé la raison pour laquelle il y a ce message `poll: interrupted...' pour chaque événement. Pour je ne sais quelle raison, libcurses réimplante l'appel système
select()d'une façon vraiment curieuse. La correction consiste à ajouter un -lc à la ligne des liens avant le -lxcurses. XEmacs utilisera alors la bonne version deselect().
Alain Fauconnet <af@biomath.jussieu.fr> écrit :
La solution réelle est de ne pas lier avec -lcurses ! J'ai simplement remplacé -lcurses par -ltermcap dans le Makefile et cela corrige :
- Le `poll: interrupted system call' message.
- Un problème plus sérieux que j'avais découvert entre temps, qui est que la gestion des sous-processus était très mal assurée : les sous-processus tels que ceux lancés par AUC TeX pour la compilation TeX d'un tampon se figaient. En fait, ils attendaient qu'emacs lise le socket qui connecte stdout...
Lorsqu'ils utilisent un binaire précompilé, de nombreux utilisateurs ont observé que XEmacs utilise la zone horaire sous laquelle il a été compilé, non celle sous laquelle il tourne. La solution est d'ajouter :
(set-time-zone-rule "MET")
à votre fichier `.emacs' ou au fichier `site-start.el' si vous
le pouvez. Remplacez MET par votre zone locale.
Ceci est un problème dû à un chargement incomplet du paquetage Hyperbole. Essayez d'ajouter :
(require 'hmouse-drv)
à l'endroit où vous charger Hyperbole.
Ce problème a été corrigé dans la version 19.15. Il était dû à une « race condition » qui n'était pas facilement reproductible.
David Moore <dmoore@ucsd.edu> écrit :
Vous pouvez faire deux choses :
1) Au niveau C :
Lorsque vous le voyez devenir fou comme ça, utilisez
gdbà partir d'unxtermpour l'attacher au processus en cours et obtenir une trace de la pile. Pour cela, faites simplement :gdb /le/chemin/adéquat/XEmacs ####Où
####est l'id du processus de votre XEmacs, au lieu d'indiquer le core. Lorsque gdb s'attache, XEmacs s'arrêtera [1] et vous pourrez taperwheredans gdb pour obtenir une trace de pile comme d'habitude. Pour faire bouger les choses, tapez simplementquitdans gdb. Cela vous informera que le programme s'exécute et vous demandera si vous voulez quand même quitter. Répondezy, cela quittera et permettra à votre Emacs de continuer du point où il en était.2) Au niveau Lisp :
Positionnez
debug-on-quitau début. Lorsque vous pensez que les choses se ralentissent, pressezC-get cela vous place dans le débugger afin que vous puissiez voir la routine qui s'exécute. Pressezcpour continuer.
debug-on-quitne fonctionne pas si quelque chose à positionnéinhibit-quitou dans d'autres cas étranges.
Movemail fonctionnait bien avec 19.14, mais plus avec 19.15 et 20.x. J'utilise Linux.
Steven L Baur <steve@miranova.com> écrit :
Movemail sous Linux utilisait par défaut le verrouillage de fichier assuré par la fonction standard « flock ». Avec 19.15 et les dernières versions, il utilise maintenant par défaut le verrouillage du fichier
.lock. Si cela ne convient pas à votre système, éditez src/s/linux.h et décommentez la ligne suivante :#define MAIL_USE_FLOCK
Go to the first, previous, next, last section, table of contents.