On Fri, 2026-08-07 at 14:09 +0200, didier gaumet wrote: > Le 07/08/2026 à 12:49, Benoît Barbier a écrit : > > Bonjour à tous et toutes, > > > > > > Que fait : ~/.emacs.d/eln-cache ? > > > > Ça occupe + de 70 Mo > > Je l'ai archivé, supprimé pour tester emacs et il me le recrée avec > > 2.3M > > juste en ayant ouvert un fichier.org avec org-mode. [...] > > Bonjour Benoît, > > Ce qui suit à prendre avec de très grosses pincettes: je ne connais > absolument rien à Emacs. > > Potentiellement les .eln se rapporteraient à la compilation native > (activée par défaut depuis Emacs 30) qui serait une production de > code C > (spécifique à la plateforme matérielle utilisée) à partir de code > Lisp > générique Emacs > > A priori la vision upstream c'est que c'est à l'utilisateur de faire > son > ménage par la commande M-x native-compile-prune-cache > > j'ai peut-être tout (ou en partie) compris de travers mais ça vient > de là: > https://emacs.stackexchange.com/questions/78160/what-is-an-eln-cache-and-how-do-i-get-rid-of-it > https://deepwiki.com/d12frosted/homebrew-emacs-plus/4.4-native-compilation > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041767&mboxmaint=no
Petite correction; techniquement un emacs récent (et configuré pour àa à sa compilation) peut générer des greffons et du code machine avec libgccjit. libgccjit est fourni par un compilateur GCC récent -15 ou 16 par exemple- convenablement configuré. Elle fournit une interface de programmation pour demander à GCC de générer du code. https://gcc.gnu.org/wiki/JIT et https://gcc.gnu.org/onlinedocs/jit/ cette interface de programmation (l'API en C de libgccjit) ne passe pas par une génération de code C temporaire (contrairement par exemple à https://github.com/manuel-serrano/bigloo - un compilateur français de Scheme vers C, ou à https://github.com/bstarynk/misc-basile/blob/master/manydl.c qui montre qu'on peut sans dommage générer des dizaines de milliers de greffons et les charger par dlopen). La bibliothèque libgccjit interface l'essentiel du compilateur GCC (gcc.gnu.org) sans nécessiter du code C temporaire. Elle peut donc optimiser aussi bien que GCC le fait, et donc peut générer lentement du code machine efficace (en réalité, en générant un fichier temporaire en assembleur). Ceux intéressés par la génération de code (j'en suis, voir refpersys.org) peuvent aussi regarder asmjit.com et GNU lightning et jitter ou GNU epsilon et Clang/LLVM asmjit.com est une bibliothèque générant du code machine via une interface en C++ (et le code générateur dépend de la machine cible). GNU lightning (en https://www.gnu.org/software/lightning/ génère rapidement du code machine non-optimisé avec une API relativement portable). Jitter et GNU epsilon génèrent aussi du code. Par mon ami Lucas Saiu en CC. https://ageinghacker.net/contact/ GNU Jitter https://www.gnu.org/software/jitter GNU epsilon https://www.gnu.org/software/epsilon Clang/LLVM est un autre compilateur C, C++ et générateur de code machine. Voir https://clang.llvm.org Plusieurs ingénieurs de la société Google ont contribué à GCC et contribuent à CLang. La bibliothèque libbacktrace fait maintenant partie de GCC et permet l'introspection de la pile d'appel du processus qui l'utilise. Détails et code libre sur https://github.com/ianlancetaylor/libbacktrace Librement -- Basile STARYNKEVITCH <[email protected]> 8 rue de la Faïencerie http://starynkevitch.net/Basile/ 92340 Bourg-la-Reine https://github.com/bstarynk France https://github.com/RefPerSys/RefPerSys https://orcid.org/0000-0003-0908-5250
