From unknown Sat Aug 16 13:47:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73159: 30.0.90; uniscribe / harfbuzz are not initialized on Windows, resulting in fallback to gdi Resent-From: Casey Banner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Sep 2024 04:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 73159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 73159@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.17259417503001 (code B ref -1); Tue, 10 Sep 2024 04:16:02 +0000 Received: (at submit) by debbugs.gnu.org; 10 Sep 2024 04:15:50 +0000 Received: from localhost ([127.0.0.1]:34508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snsI9-0000mL-8N for submit@debbugs.gnu.org; Tue, 10 Sep 2024 00:15:50 -0400 Received: from lists.gnu.org ([209.51.188.17]:41802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snsI6-0000mC-NL for submit@debbugs.gnu.org; Tue, 10 Sep 2024 00:15:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1snsI2-0005yS-1U for bug-gnu-emacs@gnu.org; Tue, 10 Sep 2024 00:15:42 -0400 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1snsHz-000860-N3 for bug-gnu-emacs@gnu.org; Tue, 10 Sep 2024 00:15:41 -0400 Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-717914d6c95so3303737b3a.0 for ; Mon, 09 Sep 2024 21:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725941737; x=1726546537; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=WYPi5FHCJSUwOmQh0HYiPjE7U+zh0EeZlhz1T7Dd97I=; b=LUkgHpMA+byqDnJ8ov3JWDtgMXQy9CDVLeEs35WFlWmolv69pIpPF3F7kwkS/deVHC SxmNGH0+JtWDb/CO2S4+k6PHBqhI3ti6Ev+SXWi6VVwkUCxfOEwmY0yJN+S/VUjYZU/J eBBXoUomqARjDBqT1YT79QiIiiVXqMdk1mXlzuPcJBU4bxkx64lIIbA2igtBNBQOJnkv yX98681Bp3TkUnlJ7o3xOaY/Zr3YVbQB7X4vlNsUCDrdzkfioV0Lcr5+d9jCCGER9ZiE i1c3i4bC2ZxVmKppISWAvhV/6wGGJbNRCpCpEz3OIOgL1PAMQKGNS0K6tKY7V004MzJe FmyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725941737; x=1726546537; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=WYPi5FHCJSUwOmQh0HYiPjE7U+zh0EeZlhz1T7Dd97I=; b=IXitvYG1wzgMoWPLkccr/TR721WvA9/UfGM6PLB10JJPJV0vLfos7WdfvJqKvzqOBz ggdP+fqXhpmzpZcrEOq05Lq/Z1OucbjbyCOK6yw3GtNKe6anOde5CvRNE8oJmvyiK40W coMRZsTHA05M4pDBGUL/yba/bEI0rhZZEH+2jOCSHDiQQU/dBkUps+0cULJjziLKfmaK Q/ULihzejihb8O/+iGRz0au0KLi61FBiqIVM89dVmwt+9E1XIVPEvroknUIhWa8CpaEo QGD3dM4YJBTu0jveyGTewFaIjBB4dkj7T846CVFebOPLcfUeExUE907x7i2O9HIyi6bd xTow== X-Gm-Message-State: AOJu0YzSb/sVK9wYIHt67SwNW16rgRsk/Pkf+qQubwQ98XqJ/244jEmm aV9U3Z4VMBLQjufyOSCvaEps/YKHR7wNcIdrGL6teTqqWjDMzCVM5HsMs7mSyYVZ1rijXcpl5Ra 5VWQkeuKElck1wtjHna3Xzv2JtxPr4pfZ X-Google-Smtp-Source: AGHT+IGrQ+lkVu9KpupTgOnWWyKK0F2sOiRFy0xaixJDf4P/Rt4JyGncrgbBM+rmz9vQNl24DCTzIizGeiCp5QaOA3k= X-Received: by 2002:a05:6a21:6b0b:b0:1cf:4c70:f26f with SMTP id adf61e73a8af0-1cf4c70f4b2mr2963359637.17.1725941736649; Mon, 09 Sep 2024 21:15:36 -0700 (PDT) MIME-Version: 1.0 From: Casey Banner Date: Tue, 10 Sep 2024 00:15:24 -0400 Message-ID: Content-Type: multipart/alternative; boundary="0000000000001dbf2a0621bc209b" Received-SPF: pass client-ip=2607:f8b0:4864:20::42e; envelope-from=kcbanner@gmail.com; helo=mail-pf1-x42e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --0000000000001dbf2a0621bc209b Content-Type: text/plain; charset="UTF-8" I recently pulled the latest emacs-30 branch (f47297782bdb5e5a07e02f119c8013d11f7d7fae), and I'm building emacs using MSYS2 mingw64 on Windows. With a build on this branch, certain symbols (from the nerd-icons package) were rendering as boxes and not their actual symbol. I suspected that this was because gdi was being used, and indeed using describe-char on any character shows me a font starting with `gdi:`, indicating the uniscribe or harfbuzz are not being used. This is not the case on the emacs-29 branch, where I see `uniscribe:` instead (and the symbols render correctly). I was not able to get harfbuzz to load on that branch, which is why I was trying emacs-30 to see if something was different there. To investigate this, I first used procmon to look at the syscalls to see if anything was trying to load libharfbuzz-0.dll, and I did see it in the trace I took, however the callstack was an OS callstack, and not from where I expected (src\w32uniscribe.c:syms_of_w32uniscribe_for_pdumber). I rebuilt with debug symbols, and set a breakpoint in that function - it was called once, but `initialized` was false so the LoadLibrary calls never ran. I'm not too familiar with how pdumper works, or the emacs source in general, so I'm not sure what the actual root cause is here. I did a bit more debugging to see when `initialized` was set to true, and it does get set later during initialization. I noted that I do not have a .pdmp file in my installation direction, which it seems to be trying to load during startup. One more piece of information: attempting to yank any text results in the error: `Coding system is invalid or doesn't have an eol variant for dos line ends: nil` This error occurs when starting with -Q and attempting to yank any text. If I call `(set-selection-coding-system 'utf-16-le)`, it resolves the issue. However, I didn't have to do this in emacs-29, so this makes me think something has possibly broken with init on Windows, since I believe this is not supposed to be nil by default? I'm happy to assist by providing any additional info if needed! Thanks, Casey In GNU Emacs 30.0.90 (build 1, x86_64-w64-mingw32) of 2024-09-09 built on DESKTOP-EK25TL1 Windowing system distributor 'Microsoft Corp.', version 10.0.19045 System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.4780) Configured using: 'configure -prefix=/e/dev/emacs-src --without-dbus --without-pop --with-native-compilation --with-wide-int --without-compress-install --with-json --with-tree-sitter --without-imagemagick 'CFLAGS=-O2 -mtune=native -march=native -fomit-frame-pointer -ftree-vectorize -Wno-error=implicit-function-declaration -pipe -g' PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB (NATIVE_COMP present but libgccjit not available) Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: cp1252 Major mode: Fundamental Minor modes in effect: tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cus-start cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel touch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process native-compile emacs) Memory information: ((conses 16 181417 72491) (symbols 48 21836 0) (strings 32 65423 2126) (string-bytes 1 4014620) (vectors 16 34658) (vector-slots 8 1231317 136112) (floats 8 196 11) (intervals 56 408 0) (buffers 992 11)) --0000000000001dbf2a0621bc209b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I recently pulled the latest emacs-30 branch (f472977= 82bdb5e5a07e02f119c8013d11f7d7fae),=C2=A0
and I'm building em= acs using MSYS2 mingw64 on Windows.

With a build on this branch, c= ertain symbols (from the nerd-icons
package) were rendering as boxes and= not their actual symbol. I
suspected that this was because gdi was bein= g used, and indeed using
describe-char on any character shows me a font = starting with
`gdi:`, indicating the uniscribe or harfbuzz are not being= used.

This is not the case on the emacs-29 branch, where I see `uni= scribe:`
instead (and the symbols render correctly). I was not able to g= et
harfbuzz to load on that branch, which is why I was trying emacs-30to see if something was different there.

To investigate this, I fi= rst used procmon to look at the syscalls to
see if anything was trying t= o load libharfbuzz-0.dll, and I did see it
in the trace I took, however = the callstack was an OS callstack, and not
from where I expected (src\w3= 2uniscribe.c:syms_of_w32uniscribe_for_pdumber).

I rebuilt with debug= symbols, and set a breakpoint in that function - it
was called once, bu= t `initialized` was false so the LoadLibrary calls
never ran. I'm no= t too familiar with how pdumper works, or the emacs
source in general, s= o I'm not sure what the actual root cause is here.

I did a bit m= ore debugging to see when `initialized` was set to true,
and it doe= s get set later during initialization. I noted that I do not have a .pdmp f= ile
in my installation direction, which it seems to be trying to = load during startup.

One more piece of information= : attempting to yank any text results in the error:

`Coding system is invalid or doesn't have an eol variant for dos line= ends: nil`

This error occurs when starting w= ith -Q and attempting to yank any text. If I=C2=A0
call `(set-sel= ection-coding-system 'utf-16-le)`, it resolves the issue.

However, I didn't have to do this in emacs-29, so this= makes me think=C2=A0
something has possibly broken with init on = Windows, since I believe this
is not supposed to be nil by defaul= t?

I'm happy to assist by providing any ad= ditional info if needed!

Thanks,
Casey

In GNU Emacs 30.0.90 (build 1, x86_64-w64-mingw32) of 2024-09-0= 9 built
=C2=A0on DESKTOP-EK25TL1
Windowing system distributor 'Mi= crosoft Corp.', version 10.0.19045
System Description: Microsoft Win= dows 10 Pro (v10.0.2009.19045.4780)

Configured using:
=C2=A0'= configure -prefix=3D/e/dev/emacs-src --without-dbus --without-pop
=C2=A0= --with-native-compilation --with-wide-int --without-compress-install
=C2= =A0--with-json --with-tree-sitter --without-imagemagick 'CFLAGS=3D-O2=C2=A0-mtune=3Dnative -march=3Dnative -fomit-frame-pointer -ftree-vectori= ze
=C2=A0-Wno-error=3Dimplicit-function-declaration -pipe -g'
=C2= =A0PKG_CONFIG_PATH=3D/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML= 2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 TH= READS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_= COMP present but libgccjit not available)

Important settings:
=C2= =A0 value of $LANG: en_US.UTF-8
=C2=A0 locale-coding-system: cp1252
<= br>Major mode: Fundamental

Minor modes in effect:
=C2=A0 tooltip-= mode: t
=C2=A0 global-eldoc-mode: t
=C2=A0 show-paren-mode: t
=C2= =A0 electric-indent-mode: t
=C2=A0 mouse-wheel-mode: t
=C2=A0 tool-ba= r-mode: t
=C2=A0 menu-bar-mode: t
=C2=A0 file-name-shadow-mode: t
= =C2=A0 global-font-lock-mode: t
=C2=A0 blink-cursor-mode: t
=C2=A0 mi= nibuffer-regexp-mode: t
=C2=A0 buffer-read-only: t
=C2=A0 line-number= -mode: t
=C2=A0 indent-tabs-mode: t
=C2=A0 transient-mark-mode: t
= =C2=A0 auto-composition-mode: t
=C2=A0 auto-encryption-mode: t
=C2=A0= auto-compression-mode: t

Load-path shadows:
None found.

F= eatures:
(shadow sort mail-extr emacsbug message mailcap yank-media puny= dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg = rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-de= code
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailhea= der
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
ma= il-prsvr mail-utils rmc iso-transl tooltip cus-start cconv eldoc paren
e= lectric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
t= ouch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
ter= m/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list= replace newcomment text-mode lisp-mode prog-mode register
page tab-bar = menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-= lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice= seq simple cl-generic indonesian philippine
cham georgian utf-8-lang mi= sc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp= 51932 hebrew greek romanian slovak czech
european ethiopic indian cyrill= ic chinese composite emoji-zwj charscript
charprop case-table epa-hook j= ka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs t= heme-loaddefs faces cus-face macroexp
files window text-properties overl= ay sha1 md5 base64 format env
code-pages mule custom widget keymap hasht= able-print-readable backquote
threads w32notify w32 lcms2 multi-tty move= -toolbar make-network-process
native-compile emacs)

Memory inform= ation:
((conses 16 181417 72491) (symbols 48 21836 0) (strings 32 65423 = 2126)
=C2=A0(string-bytes 1 4014620) (vectors 16 34658)
=C2=A0(vector= -slots 8 1231317 136112) (floats 8 196 11)
=C2=A0(intervals 56 408 0) (b= uffers 992 11))
--0000000000001dbf2a0621bc209b-- From unknown Sat Aug 16 13:47:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73159: References: In-Reply-To: Resent-From: Casey Banner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Sep 2024 05:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 73159@debbugs.gnu.org Received: via spool by 73159-submit@debbugs.gnu.org id=B73159.172594752822957 (code B ref 73159); Tue, 10 Sep 2024 05:53:02 +0000 Received: (at 73159) by debbugs.gnu.org; 10 Sep 2024 05:52:08 +0000 Received: from localhost ([127.0.0.1]:34666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sntnL-0005yD-RO for submit@debbugs.gnu.org; Tue, 10 Sep 2024 01:52:08 -0400 Received: from mail-pf1-f171.google.com ([209.85.210.171]:45291) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sntnJ-0005xi-UK for 73159@debbugs.gnu.org; Tue, 10 Sep 2024 01:52:06 -0400 Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-717934728adso3727771b3a.2 for <73159@debbugs.gnu.org>; Mon, 09 Sep 2024 22:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725947455; x=1726552255; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=UCRdrY++KVeOpTxtg7MMuqdm9yEMkZvtYP8q92NwKNw=; b=gykquNk139HLn+hFWwmnmuJhsH7yxzlYci5tmtDkaDHAPcFfuNm3TZ/LXG+gILRnsx Ww23NmbGdQFN9YVhBsAq76h2WPdm5vNpfe/8h/W7Jl+DEl9LPqgoeitJcx5dwKus5oB7 FkV0D1C844XSLgg5VO3VALDKNbYlZoytVtyx5QteF9FP7DBYAJP5UHCC/nO4hm60b9P+ HAVH9gKFYChyH0h5hMG95ELl2qoKcG59w2wCaQyuuW633XriKeAFHGq7ZNL0g+pJkh3a qR0UHkcZRm3a8Yk8PC/5bklV9/Vu12ONTl5eTm7NGToBfcrbEJhWfbqupGgNQLq7XFcN qHNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725947455; x=1726552255; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UCRdrY++KVeOpTxtg7MMuqdm9yEMkZvtYP8q92NwKNw=; b=iCT9y8k0X+fyIRfl/lExxqdYNFi6maWV+LLXZTjNoVMIr8G2AF3fpkI+JfPH035bt2 mZosKnPSoVwEllWL1Nw+AMEF6mFmk1Hu0V9Wua/R39DbDUU470aX6n1mgvVkrfv+j6A1 e/1fIWSzTzLn1DzssS/vkLQblDQ5P/YL0JbK3ni7Hf/R9Bc8jzmDnhscG/KAc6s/2UCm pIFAsggypziMGPY6FrZsHnIcAdf5AqG3Yc6xHTk3kzcfjZLz4p3JK7d/WSMkMT+mShQ9 Oz0nn7KKlqVSz7Aid/1Qi70677QOt4JGrgBDHrA3YfO7Sh396J2QS/Lf2Hkg2r1s8O9w EQKA== X-Gm-Message-State: AOJu0YzGZN5q0fG4vjsoqPDEOFf9YpGSJDusLvBdoW8671c3MEAAUGCx 3Bj7+YZ9viYt28ppiPM+uGg34RXiBpvrzEMpQb8zM/u7BTvQTsLleJ6ZQVUKvs6YhMCdU4h+47T LVLO6uCFstEI3Ke+KOEof7JO4RffgIiXr X-Google-Smtp-Source: AGHT+IGf0Fc7dN2dAGBdHXF/MngNHVJKa5cFWre8WyyN/zYIzxmCCXaLB0eGmO1AA00L2mAd17ZJfT7uZGrYENfwWIY= X-Received: by 2002:a05:6a00:2d90:b0:717:8ece:2f8b with SMTP id d2e1a72fcca58-718e3fe6a8bmr15488758b3a.17.1725947455003; Mon, 09 Sep 2024 22:50:55 -0700 (PDT) MIME-Version: 1.0 From: Casey Banner Date: Tue, 10 Sep 2024 01:50:43 -0400 Message-ID: Content-Type: multipart/alternative; boundary="000000000000f4e8930621bd740e" X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: This actually seems to be caused by the pdmp failing to load. `make install` installs the pdmp file as `EMACS_PDMP = `./src/emacs${EXEEXT} --fingerprint`.pdmp`. However, this is not the filename that emacs tries to load - it attempts to load it from the wrong di [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (kcbanner[at]gmail.com) -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.210.171 listed in wl.mailspike.net] 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.210.171 listed in list.dnswl.org] 2.0 BLANK_SUBJECT Subject is present but empty 0.0 LOTS_OF_MONEY Huge... sums of money -0.0 T_SCC_BODY_TEXT_LINE No description available. X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) --000000000000f4e8930621bd740e Content-Type: text/plain; charset="UTF-8" This actually seems to be caused by the pdmp failing to load. `make install` installs the pdmp file as `EMACS_PDMP = `./src/emacs${EXEEXT} --fingerprint`.pdmp`. However, this is not the filename that emacs tries to load - it attempts to load it from the wrong directory, which fails. That seems to be why `initialized` is false, and why uniscribe / harfbuzz is not loaded. If I rename the emacs-.pdmp file to emacs.pdmp, and place it next to emacs.exe everything works as expected (and emacs loads a lot faster!). I did a procmon dump to see what .pdmp files emacs.exe is trying to load, and it attempts these locations: - E:\dev\emacs-src\bin\emacs.pdmp - E:\dev\emacs-src\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs-ef314e5e05618ae9e98f9cccc0769b2adce721d1b3bac00e305e61b4d457b0a4.pdmp - E:\dev\emacs-src\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs.pdmp The thing is, the emacs version is 30.0.90, not 30.0.50. A strings dump of emacs.exe: strings emacs.exe | grep 30.0 %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32 $Id: GNU Emacs 30.0.90 (x86_64-w64-mingw32 ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB) $ 30.0.90 %emacs_dir%/share/emacs/30.0.90/lisp %emacs_dir%/share/emacs/30.0.90/site-lisp;%emacs_dir%/share/emacs/site-lisp /30.0.90/lisp/ %emacs_dir%/share/emacs/30.0.90/etc %emacs_dir%/libexec/emacs/30.0.90/x86_64-w64-mingw32 %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32 So it seems something is going wrong with setting the path. I noticed that exec/configure.ac has: AC_INIT([libexec], [30.0.50], [bug-gnu-emacs@gnu.org], [], [https://www.gnu.org/software/emacs/]) I tried changing this to 30.0.90 and re-building (using make bootstrap), but the resulting binary still has 30.0.50 in it. --000000000000f4e8930621bd740e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This actually seems to be caused by the pdmp failing = to load.

`make install` installs the pdmp file as = `EMACS_PDMP =3D `./src/emacs${EXEEXT} --fingerprint`.pdmp`. However, this i= s not the filename that emacs tries to load - it attempts to load it from t= he wrong directory, which fails.

That seems to= be why `initialized` is false, and why uniscribe / harfbuzz is not loaded.= If I rename the emacs-<fingerprint>.pdmp file to emacs.pdmp, and pla= ce it next to emacs.exe everything works as expected (and emacs loads a lot= faster!).

I did a procmon dump to see what .pdmp = files emacs.exe is trying to load, and it attempts these locations:

- E:\dev\emacs-src\bin\emacs.pdmp
- E:\dev\emac= s-src\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs-ef314e5e05618ae9e98f9c= ccc0769b2adce721d1b3bac00e305e61b4d457b0a4.pdmp
- E:\dev\emacs-sr= c\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs.pdmp

<= div>The thing is, the emacs version is 30.0.90, not 30.0.50.

=
A strings dump of emacs.exe:

strings em= acs.exe | grep 30.0
%emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32=
$Id: GNU Emacs 30.0.90 (x86_64-w64-mingw32 ACL GIF GMP GNUTLS HARFBUZZ = JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SO= UND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB) $30.0.90
%emacs_dir%/share/emacs/30.0.90/lisp
%emacs_dir%/share/emac= s/30.0.90/site-lisp;%emacs_dir%/share/emacs/site-lisp
/30.0.90/lisp/
= %emacs_dir%/share/emacs/30.0.90/etc
%emacs_dir%/libexec/emacs/30.0.90/x8= 6_64-w64-mingw32
%emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32

So it seems something is going wrong with setting th= e path. I noticed that exec/configure.ac has:


I tried changing this to 30.0.90 and r= e-building (using make bootstrap), but the resulting binary still has 30.0.= 50 in it.




--000000000000f4e8930621bd740e-- From unknown Sat Aug 16 13:47:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73159: Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Sep 2024 09:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Casey Banner Cc: 73159@debbugs.gnu.org Received: via spool by 73159-submit@debbugs.gnu.org id=B73159.172596059031504 (code B ref 73159); Tue, 10 Sep 2024 09:30:02 +0000 Received: (at 73159) by debbugs.gnu.org; 10 Sep 2024 09:29:50 +0000 Received: from localhost ([127.0.0.1]:34885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snxC1-0008C4-T0 for submit@debbugs.gnu.org; Tue, 10 Sep 2024 05:29:50 -0400 Received: from sonic301-31.consmr.mail.ne1.yahoo.com ([66.163.184.200]:45639) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snxBz-0008Bq-US for 73159@debbugs.gnu.org; Tue, 10 Sep 2024 05:29:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725960576; bh=iuVfsWh6Y8h3cRrBm5pNwfX9u6yE9u0Xula5d4WRCas=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=rVb1xYMKqEvAXDhgxShJX3TMpIQM6Iqg7YCYFzuw3KCEjE9Ksq5RnLpxOrul/ccVFo5WGKdqI9S8+ZqRhgh5GCCr+Xv7ZJw9k2OLhxBQSQwUpHZx42KPx7T2cC3RO9kMVyafzGTEyPmZghJcRIwf4pDDkDlu+/Mz/UWhH6KX+cPysBVcv3Jk/DoARr549wtYPqhh8NI6OZRnBZeCn27eiGuIZOXtQyZFdRYTu7MocpBVzNjTLqS3lJ0wJ4GOpXxamhuixc8m72DXUFObygozUXWIRJPOTaTmWk3qTUvntruBwKL6efoOg6DVOYdAnFIt4j5ttshFyGTcU/sCEb0xlg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725960576; bh=TyULvRwfFsBsJmtGmjlKaEu1oFl6xdzngGIMK3e1FtA=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=fT8uqj/PX2wbPkFmMqPEblUntGBft+dF/uM++enYqCfxgX3HB4KBuzhQYYmUqmpRFI9Av388p50YK3fGXOVJpcO06DFFlNk/zSaikuZqSJ9xTEGPn9L28LeQZ+T+v0Bo9icPlJQOm1a2yFHmr2h+fZ3vBf6sp5+wAHxXAKvAnr/ThH6E5TVzHtBjjkoPKG5vadrcAUZMq43Ub4XZApxLynyK22JG2L0/wT3JON7ehoavAga1MSFg1y13q8xRLMmiRFHaWUf36BCEy5JxOU7TjQUHcivO1rVS4Qwd/AIY5PK6ChSYXYKtYMbAYR/+8H0Ly5+JRWSgbRqLwfMKafYmNA== X-YMail-OSG: zm4fA4YVM1lG1gY4XpI9oerDUpA.1zjfUsargC2al4WNXg77jgncYMRo9JpUFv_ 6EDmue2GWwmPO6PvQS8AQGI0XhucbtCBVTSTz3ShxePvOUBRNEBfLqv8yrgrjAltvbYSWLNjK9f4 CjpCHE5wF_Y1zW5tlGI1r70mVFNqLbXj6.qBPChlBfpvG71mB3UJJ9sZoj9iKt9Fm_b4l3xEl6ln RdkNup9M1GJlPHU2XAV9xYNcgI5NXuPXbAPX6lh6sdNGsN5hxRKkZHSJn.scEtcQpoZls0lAV5ur VoutK8rFTzevYBoLe3UbRhKm.8AWJyRQly3iBnG_jOdZYv9Xa7B4fSJUuZG3VdRk3CoDVdy1iJSP aPWnsxAuC8GexP64.uxcYjO9OwzI8qkg4uhTgQaRtMu42If.RjPLLI5QYv9vRkGY1u_Z55OIM9Bv v2uYJKIOD7ew4.YbEASluZ3RpzZS5p2eRt2n5tM5IIfatRO04QLoH9_xyyuWFgRtBC3Hfd.xWx_l en4WEjgMOH09ic6VCRibq7fvyK6BRctGYA8k1186sRDqgIO8e4xmY8Fja0dOFA2S598WSMOKAieq bveQOg7.HlvBYuoaExif_JCh_knAQiCjsWfkw7CMh_IxudZfZGngvg5DZbImTN6MOKUmj7ntrmSf 1k3dWI31.jVnwDEj8ojhUniPph6I38BREwvTIkcH6i7keQpYLoOS8n9wI6.APuJHgQS8zpv7cIml E7MVlUTRX_kQuDR3WnylXGBUMb7S3zPbSlRp2m9CRmmp4PIf2C_7VdYxaq7B5oUsp3Oed_N6JVcb C9KoduePbTEDwWf1fT50vwiibyNrXr_yNR4oOoHxN.Es1i2PRS2TOKftUVkJ6k8abjjljbI5pau1 MVi35ohlUl6jWaw_S1HsDxs9b0zAH22gEsY9jq3tyXOSBMSF0EHCEp47WI6jOPeLVoeY6O2jAN7K CRcdg4foA_y1DoP5fbT2H5jjEBxLMX9SIU_LD_5Kt7WMu__Iu5.EI4yKPArU5hUelX5O65zJ5GH2 4BP.b.7bg.Y1LVvZtOt_D3S7.li_XnsXxQuWq86diuUIIy5qlH1WhmUQSd0DZ9dESueEoz9w266s yUk0tNrkgWEze.H7etpdIFtx8EOnYqwNH5GuWBgPYynrAYoSq3mtXjf9EtDMTInVNTw.sebAe34i zHdE4I6rPet.Kj_AnPl4d7b8RZ6bjeb7.dQTvkS19B2SstAK3ZqOeEx14WLama5a95O4oojGJ3Ay t3cYChV9N0OPtm5Lxkt2pp8T.kPqzq9PdeVOv60i5gUiuYmpGl7JCs1t21nlPW1ysGTspcnpKGCL j.oBXk4ZLM86txmm.7Zlst78LbAPqM9Qq1IyVH5wscwudqFpNjz9lLsAcQIpej508_6SGAdhtAeT g9x9LtgNY4l.TARkYeJFbEzfG.2paC_5h4Cxcv1cXnxnOWdc6d8DpH2MoSsjDEatUKeLmK7ubVZT jZa3nOMcO7lI9CowUj_ADCP6quODVB0D_qNUgmzpeB65fW6Hz8pf9HgppAEU2HcMafcutgjR2Azt wkDvEIZCugLyKJUWtrjgTieal3XkekwZLG0UzM7pyV9eYyMkGmx9T_ot.Svu0.wRrprWkdvEh8A3 .MbcJbUgHD1aqtZhSxiDEFug.1PGw6YJpqKjVl6a.AZqL_rYatoTQz2I_9SbtDYdWAXhRFqF74Oc aLbuKUXfQXw5rX9Wt9chWxTM2NpG8613zt1BicR3AZJDHG6wg9iuedsAGNkNbavWFqEWIumPhp9f qTVvV_p9c6M.wTGVaFjF7CEb3ljzmGr5g3Yoqvz.e4gLJfVOfKQsbMTFBLnMdWNlLOomCH0G2L34 B3Gkhqy9PrChiPzM3lwnVNUQnBCr_yte7pJQoms_pMSLracBgHN8OM4ZHuJQYunqh96T6U0LSwBs 5U7ok4a9tIJnIXlDliBYeeyNgZRB4Ux9az0ra7MQCIeJ8BtHrNhZbPFXaj7QE6S6pst9oB.HYEbv wHFSAr1p8BCvuxmfj_esV29qp2GosTrEjJix1stnmoau5bv7_jzfgfAkgJdipENPh.ty8q9Y5YFB RXAW7MK0czkHle8pG2GrxrLl09X.kzlzUQyXaSjlQ6RLSAtjmrmYrvDrDVwZM0YJcvd88kN01MrG HUfPMiBJ9MJRKo4hW5ne4oNV4UIi7d9i7DleNki7fJ5slsTMSNUfIFxZbCR6x2wQDLUw6GoTLmXx o7gZJ3iql4ATIhZ1esAOzpFtXOcEe3GiR5JpxgkcaldguFgo8M4cOjg_1LxGx X-Sonic-MF: X-Sonic-ID: e7252d7e-071c-4554-af25-a67dc2193cb3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Tue, 10 Sep 2024 09:29:36 +0000 Received: by hermes--production-sg3-fc85cddf6-fmmw4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d28574d094a461c0922c34b16a5acd80; Tue, 10 Sep 2024 09:29:33 +0000 (UTC) From: Po Lu In-Reply-To: (Casey Banner's message of "Tue, 10 Sep 2024 01:50:43 -0400") References: User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 10 Sep 2024 17:29:27 +0800 Message-ID: <875xr3rh54.fsf@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.22645 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 318 X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Casey Banner writes: > AC_INIT([libexec], [30.0.50], [bug-gnu-emacs@gnu.org], [], > [https://www.gnu.org/software/emacs/]) This version number shouldn't appear in any binaries built for MS-Windows (or otherwise than for Android in general), and its value is not really significant even there. From unknown Sat Aug 16 13:47:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73159: 30.0.90; uniscribe / harfbuzz are not initialized on Windows, resulting in fallback to gdi Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Sep 2024 12:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Casey Banner Cc: 73159@debbugs.gnu.org Received: via spool by 73159-submit@debbugs.gnu.org id=B73159.172597086832459 (code B ref 73159); Tue, 10 Sep 2024 12:22:02 +0000 Received: (at 73159) by debbugs.gnu.org; 10 Sep 2024 12:21:08 +0000 Received: from localhost ([127.0.0.1]:35004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snzro-0008RT-Gj for submit@debbugs.gnu.org; Tue, 10 Sep 2024 08:21:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53650) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snzrm-0008Qb-Fw for 73159@debbugs.gnu.org; Tue, 10 Sep 2024 08:21:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1snzrc-0002uv-5c; Tue, 10 Sep 2024 08:20:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=nzrQxHSLwZ1Li7BsRQ7g79GQ48bbvOlVSZBeuOLKaEs=; b=ItinamjX8cAm D6Pzv2tGX/I39t9jFF0S8JIxQMIE32SEZYjfJUw4vWfFs3STBHJtuYcSjMN9mEhxHgaqw0DPrfiCF bWq5USno2bNM5dLsNeXs/CodSmF0e4VzdLb0uRzO/cgLr1eQlAInbHx0P+1yKgjXHqU4uC9G2Knc4 9JuFlDodusBTWdNiqmI54kqbdkPJvRnnU+xqHqXjmpnM2qKPQXQvpKpn+54d3tjnNjBTlABspNB0/ tu/p1s8pLpeXlsrdkf7r+rf3EbvWuQ4vGpRiIpJtaBMXthgsyUIX2le9aGO1KcJPaxFf7P/VQYaut WD/bwQfSZF3l32dkeEBuxw==; Date: Tue, 10 Sep 2024 15:20:54 +0300 Message-Id: <868qvzvgwp.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Casey Banner on Tue, 10 Sep 2024 00:15:24 -0400) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Casey Banner > Date: Tue, 10 Sep 2024 00:15:24 -0400 > > I recently pulled the latest emacs-30 branch (f47297782bdb5e5a07e02f119c8013d11f7d7fae), > and I'm building emacs using MSYS2 mingw64 on Windows. > > With a build on this branch, certain symbols (from the nerd-icons > package) were rendering as boxes and not their actual symbol. I > suspected that this was because gdi was being used, and indeed using > describe-char on any character shows me a font starting with > `gdi:`, indicating the uniscribe or harfbuzz are not being used. > > This is not the case on the emacs-29 branch, where I see `uniscribe:` > instead (and the symbols render correctly). I was not able to get > harfbuzz to load on that branch, which is why I was trying emacs-30 > to see if something was different there. > > To investigate this, I first used procmon to look at the syscalls to > see if anything was trying to load libharfbuzz-0.dll, and I did see it > in the trace I took, however the callstack was an OS callstack, and not > from where I expected (src\w32uniscribe.c:syms_of_w32uniscribe_for_pdumber). Where did you get the libharfbuzz-0.dll file you have installed? Is libharfbuzz-0.dll in a directory that is on Path or in the same directory as emacs.exe you are running? And what does the commend below print? objdump -x /path/to/libharfbuzz-0.dll | grep "DLL Name": The main problem you have is that Emacs is somehow unable to use HarfBuzz. All the rest is less important (the fact that Emacs on the emacs-30 branch was unable to load Uniscribe is indeed a bug, which I fixed just now). So let's focus on that one problem: you should be able to use HarfBuzz if it is installed correctly; it works for me. > One more piece of information: attempting to yank any text results in the error: > > `Coding system is invalid or doesn't have an eol variant for dos line ends: nil` > > This error occurs when starting with -Q and attempting to yank any text. If I > call `(set-selection-coding-system 'utf-16-le)`, it resolves the issue. This is due tho the following, I think: > Important settings: > value of $LANG: en_US.UTF-8 <<<<<<<<<<<<<<<<<< > locale-coding-system: cp1252 How come your LANG is set to en_US.UTF-8? Did you set this in the environment or something. Using UTF-8 as the default encoding on Windows is not a good idea. From unknown Sat Aug 16 13:47:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73159: 30.0.90; uniscribe / harfbuzz are not initialized on Windows, resulting in fallback to gdi Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Sep 2024 12:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Casey Banner Cc: 73159@debbugs.gnu.org Received: via spool by 73159-submit@debbugs.gnu.org id=B73159.17259716202340 (code B ref 73159); Tue, 10 Sep 2024 12:34:02 +0000 Received: (at 73159) by debbugs.gnu.org; 10 Sep 2024 12:33:40 +0000 Received: from localhost ([127.0.0.1]:35015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so03v-0000bf-UD for submit@debbugs.gnu.org; Tue, 10 Sep 2024 08:33:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46296) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so03q-0000bO-QD for 73159@debbugs.gnu.org; Tue, 10 Sep 2024 08:33:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1so03g-0004UR-GV; Tue, 10 Sep 2024 08:33:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+mzZtIcXvJAtSigK0NrWs5ZDs0g3Ht+L5qLJ31Eo7iM=; b=RflJllBQiyRI +H7zE7KHP+A6fn4T/NMqkrwd3+XrlZcw+3GT0yn7bbxXEBvRrDLAOfjL4fUTtXKdnFjyYbMqggHhp 6aP/xV24j28xqcSu+izsSidOFJykRRN+s2w5hZiiJvjv6ydZWWeAamgC/o6mA7t3qDsAkz1GEW1Ll WHILF9xMcp1r/TdRQL4YV71SQEevoi4cWl6okacwD5vYj6eUwuDFErRijwGdKVv3bJv3dEQamQ2P4 eIZhzC8HzqrNOzjqoVL3NwGm2blsILCYH3S/WL/p2qjhn5Emc1X1pT65PNY04uIgCN4YdZPmqg5AK OYT0VbrSNY4jqEFSKyTm8g==; Date: Tue, 10 Sep 2024 15:33:21 +0300 Message-Id: <867cbjvgby.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Casey Banner on Tue, 10 Sep 2024 01:50:43 -0400) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Casey Banner > Date: Tue, 10 Sep 2024 01:50:43 -0400 > > I did a procmon dump to see what .pdmp files emacs.exe is trying to load, and it attempts these locations: > > - E:\dev\emacs-src\bin\emacs.pdmp > - > E:\dev\emacs-src\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs-ef314e5e05618ae9e98f9cccc0769b2adce721d1b3bac00e305e61b4d457b0a4.pdmp > > - E:\dev\emacs-src\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs.pdmp > > The thing is, the emacs version is 30.0.90, not 30.0.50. > > A strings dump of emacs.exe: > > strings emacs.exe | grep 30.0 > %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32 > $Id: GNU Emacs 30.0.90 (x86_64-w64-mingw32 ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 > MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF > TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB) $ > 30.0.90 > %emacs_dir%/share/emacs/30.0.90/lisp > %emacs_dir%/share/emacs/30.0.90/site-lisp;%emacs_dir%/share/emacs/site-lisp > /30.0.90/lisp/ > %emacs_dir%/share/emacs/30.0.90/etc > %emacs_dir%/libexec/emacs/30.0.90/x86_64-w64-mingw32 > %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32 > > So it seems something is going wrong with setting the path. I noticed that exec/configure.ac has: > > AC_INIT([libexec], [30.0.50], [bug-gnu-emacs@gnu.org], [], > [https://www.gnu.org/software/emacs/]) exec/configure.ac is not used in the MinGW build (but the above is a bug nonetheless, so I will fix it shortly). I cannot reproduce this result: > strings emacs.exe | grep 30.0 > %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32 Please look at src/epaths.h and see how PATH_EXEC is defined there. > I tried changing this to 30.0.90 and re-building (using make bootstrap), but the resulting binary still has 30.0.50 > in it. As expected: the MinGW build doesn't use that file. You should regenerate or update src/epaths.h. Perhaps touch src/epaths.in and then re-run "make" in the top-level directory of the source tree. From unknown Sat Aug 16 13:47:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73159: exec/configure.ac Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Sep 2024 12:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Po Lu Cc: kcbanner@gmail.com, 73159@debbugs.gnu.org Received: via spool by 73159-submit@debbugs.gnu.org id=B73159.17259720784018 (code B ref 73159); Tue, 10 Sep 2024 12:42:01 +0000 Received: (at 73159) by debbugs.gnu.org; 10 Sep 2024 12:41:18 +0000 Received: from localhost ([127.0.0.1]:35020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so0BJ-00012k-VH for submit@debbugs.gnu.org; Tue, 10 Sep 2024 08:41:18 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so0BI-00012W-Aa for 73159@debbugs.gnu.org; Tue, 10 Sep 2024 08:41:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1so0B7-0005Wr-Ol; Tue, 10 Sep 2024 08:41:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=0Pq8DeDOtzvhCCvj36AoHCNs3eSBCn0oDdRO++0kbww=; b=OpudEbVla8r+ 9U2LUX9oTw/6pz/xDL9KYm/LOgqH0RFOlg5koVpueGVKDc1FFY+/r0s2FjYCi15/HMjhOCfxLs13D Cwj5KQLQlDS20SfFLOlUKezAdgxGmlYPB48a+ngr/RU8PpsXglOlG1Q7rXv7YmS0Z1h6STDp5sd1M naQ29iRR/zMWuisIv/b1+rvNU4m74wUwr8ZXSMZA1KycRnC51TVuKJ7CGRYxDqFbbT12s3MzXwz80 Ru25qkUmktmg76/UoAQdlV/nqHOQhdE3nUkLknwb8uN1rhpvVLfqgtDz1nvw2bAlsHdlWyS16iyVE yoGlrRfq8s4/BadlNeSmDA==; Date: Tue, 10 Sep 2024 15:41:03 +0300 Message-Id: <865xr3vfz4.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <875xr3rh54.fsf@yahoo.com> (bug-gnu-emacs@gnu.org) References: <875xr3rh54.fsf@yahoo.com> X-Spam-Score: -0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) > Cc: 73159@debbugs.gnu.org > Date: Tue, 10 Sep 2024 17:29:27 +0800 > From: Po Lu via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Casey Banner writes: > > > AC_INIT([libexec], [30.0.50], [bug-gnu-emacs@gnu.org], [], > > [https://www.gnu.org/software/emacs/]) > > This version number shouldn't appear in any binaries built for > MS-Windows (or otherwise than for Android in general), and its value is > not really significant even there. Unrelated to the problem of the MinGW build, the fact that exec/configure.ac is not modified by admin/admin.el:set-version is a bug, don't you agree? We should have 30.0.90 in that file, not 30.0.50, right? From unknown Sat Aug 16 13:47:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73159: exec/configure.ac Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Sep 2024 13:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: kcbanner@gmail.com, 73159@debbugs.gnu.org Received: via spool by 73159-submit@debbugs.gnu.org id=B73159.17259737139200 (code B ref 73159); Tue, 10 Sep 2024 13:09:01 +0000 Received: (at 73159) by debbugs.gnu.org; 10 Sep 2024 13:08:33 +0000 Received: from localhost ([127.0.0.1]:35036 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so0bh-0002OJ-IX for submit@debbugs.gnu.org; Tue, 10 Sep 2024 09:08:33 -0400 Received: from sonic301-31.consmr.mail.ne1.yahoo.com ([66.163.184.200]:44116) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so0bf-0002O3-EU for 73159@debbugs.gnu.org; Tue, 10 Sep 2024 09:08:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725973700; bh=GJ5TqMUKSmmeV5fZq4rPfBP9Uc45utR8ggZ1OdQw6X0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=CmI0cadNFh5/9DYL+k0oMeI+C4luVaoIBFEznMXH+jVBJLFOobld3XdRuz/LbVLe0UucASsmxth4LH60mkaUYkYOe6etHVC/4QX72NNuQH7jIRIEXP2HJX3wES8wMPWVU63PoG3SRG8xAQ/TpbuNhvNPo37Z68uYdJPfEb622ZhW8ocznikETYI5sZUyAJOG4rxzlJW2Qh3iRhpuwHVMxXGjaNOYtg+LEKlPMFrXJetAhOcve1caf89ppqU5g/G/rkpiVCmi3853/IG2rK6iPKrgdW2NOG1Y/p3G3V/xL6RQqRgi4G6QOzhsEXhxXDcZkqjvOX96W5HljkpchBOIMg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1725973700; bh=RBwPLOKn8w7SwmC1fean9pI8FXmfVO6J+Fcyqh9aNq2=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=fRm5nE/pFTB0ibZJxlfHI12MCTm9KCrMrVLFI56XJQh3rqcLoSlqix7ma0N2cXj3GH+M5WlO9efGUVwHdQSElnm86BWrD99zsyxe+5e10sjxTt5iNytG9aK0c4LnXOlGiVd4PnaWy+pJwgFsWZZfZlihwYzET3ux85jsvPASAZrnNNaeHMsrVckLlyKpYlsR5j+clG/a9tQHwAl6VxYvknZ6MsY0Skh+/ZZ7IUDUypbXE0bZQw59xVx3giq7lg2UYt5ZWRKxPv3sKSPEj7EjE6KOd7S/eMuGk3UBO6QoE5Zm0D0/B531o12PFlB6WizBZDUpwkVCyaqs2G2tY5vrcQ== X-YMail-OSG: jN3RQKQVM1n4v_lGmdS0n.wko07kgYsekkg7giBiyj8jVIXTD5pkL4AVfPn3l9i hvs1WSZ.Wk0sb5q4zTB_Jwn3ouNxFJz.2rCRMnXRIQNgfrlQ9XxB9kcl3PWzt4qSN6m0DKwHwXjd kyV5pAup3rfxdMPTUZr_020DwO7MRQx4aH6vIoraxscJZUXeM6OZGhc._swfAJgk6ZoFf4FZbAvW CcxXVWvhxKtyWpf7s8Ic4Tfk.ZR_R9FbD0WweVysvZUvY4VmhYKf.cfyna8mDjBuIo9YYjPFM2ME hXcd8UDRKxeQFO0OMyTgtoKa012u7LkClk19KEciXjjtwWP6lZYJnQlnJTrGP7_aDZY1QmbYgatN OVIryB_embpuzyrIKQpw_OuVX01Q5MaWq8PFPEtzSxP0nwfseL0ucRQn10UmYaHCzNqeg1.P0Hzk XlLL6cvLLeais6AtbD0IvsI613JFBo_XWqHI0Hqs.ueI507Bfi9aC4BoeITmZhHLPqIDUB25w9Sw w6KT2oPau0N6T.2Kw7xPSEJqyZBxK4PJllD4NIwunDv7J9LxA9T_LA_L59lzAJHkkCfmHZiK6JZO YC7Yy3mr1A92su_pikCigaOU3ImboGKGy_._0ZfjjxfnipmYon_pN9ls6Vdb543cGCYqWS.epjGU djD758d3TUp1p5ts7pqtSPf.n7IE64bNFt2mkqBfzCg2fSNNjJMAYHn_hNAKhiXvMwN7kfOsQ9lY oKmknF8D6QIWTagiwhfSR__.Be9asRdPU2awjMHb8y7Jf86Q0DLNCmbnpJak4.bS88VYUTVY6qGx 9_JNiew6hSqty9OQdaxTyf0Zd6NDltlJwCoZHHY4dL80VS5HUTlylqlfiIwuVy_xxDhrZCo4tkKR J6XESizjPeD9m.uoq02j.HM4pVU9.VYB49knkJ_nMaGulSId.dklKfKf3RQUaHCD8bo6g0AUzUla sCnTgVG4R2c8BgRTsSOFhA7Cit2N5aKMLZVo3fm.SVgjfKrRfe4p1uHuwv.0EbE4CS2z8yhvJm1r vjV8tvjoojL91M1DTJJ5VZ47sYBpayLORJYwaAUrZ1T5LOD0iEQ2T9QiCwETR0_soziWZrN_5mZT BrsHwfRkyzUEMSkQLnrcB.BmKmUBvRbpEkHQr0w6Acr2TwnuWeNif29k1JivwiY9kKBgJ6MTNViD YVIV7Wcj.VUVhl39eDVY9mNHGy1XXeRn4lX_Fhf4C6R2fJvgGXXoODOQb_CTPK4eE8XC4ZHpBhNk mTY43FODwFLIveTAvhL2brVuXbtWcWr4DnvJoFY2bVyPpgTVlyqlOL3cTysdCGJId7mo6JuItU3S lmYWsIHcsAbFA5wyK.PPEPkOE5OYcbQIEGJaZI_zxXx3ECNpislGEmGGbva._jodVbdl5yQnRnuQ vKnoLHZZr9uER7gpXBj1RQ6ygxn2mVEftRh2wRx1QrS20kqV4PFAEAnhZcgphl0chlyhuFkYZiTL lEcYZWbUQN7Srzeh._BblYAaiWyWSS942nyaxy1Qtsi1vTqmE7vOSLDUiSmqADRD0pqfhcHDwPeQ ibcO_DwirdpnFoGLYBZf1o7MyX0XlRnu6xe_yrVo54nya9EtkmXzceWHfky010AbDT.YkKXNTrj2 YFsYPrj6qBKFkjmvWB8WUNbNrQ6KJD.lfILEuvRN6l93W3b5UX2YlFa0AslTdqncFksQwK8bA_Tu tF7LRmNh9IVMdhm13drBVXhl0PriTXljlYNvdOSWT3cYqICVan.GuDOf9hSG6VJOEwszwbUaQzSH EK0ta3aHbBE7psfBw0bhrD.LjJLMD6OzO.g9vVdDkG54ema9HRpG4VBk2BUWrZFiJiJmvQXfb09Y YFOAbL.HJlk0b5WUox01r0dvNAG__By5pCeQO4ZztVmG.rLbFvE4h8xiO.oVEKmH5IrXbhaLxaeF NVHb9NapKHSI0Rpn236dgMDjRtMfv6RLKqzNr5QWqtjXr81zEUS8t43B_HrWERPprKQpTRHuERs9 uu6KzokIqbVNNq6MIAcutyj60KB4tkOTeCC33ZPcVsqZOp.n_G0_mcVZd3OQTsKiZ4R3KEo9S19V Q8yE82enmLzPdqgHeWoeY94Kgu5pxIofg3VCdQa_8tKzrt4jBTdKRMKA8Xs9NriwNTfVGdpj78lw qny5JarcjBUpsyxG0CGGbsvev5HRV1vwolw_87mJ7YxWJ1M2NLmPP02VvPcji8Y46r2y1KaGj0kh LBWPKpSZHTPPTj5AMIRhj2KTmLFM4ZMtsfGrt8_wZFBB6vJHx13ex9jntgXGn_KRZ_fA- X-Sonic-MF: X-Sonic-ID: 963b2b60-0ac9-4e42-a1c1-c467ce2ce858 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Tue, 10 Sep 2024 13:08:20 +0000 Received: by hermes--production-sg3-fc85cddf6-lbhm5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 261be586fe92426ff6b90f1f501cc1d2; Tue, 10 Sep 2024 13:08:17 +0000 (UTC) From: Po Lu In-Reply-To: <865xr3vfz4.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 10 Sep 2024 15:41:03 +0300") References: <875xr3rh54.fsf@yahoo.com> <865xr3vfz4.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 10 Sep 2024 21:08:04 +0800 Message-ID: <87zfofpsgb.fsf@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.22645 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 302 X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: > Unrelated to the problem of the MinGW build, the fact that > exec/configure.ac is not modified by admin/admin.el:set-version is a > bug, don't you agree? We should have 30.0.90 in that file, not > 3 [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [66.163.184.200 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [66.163.184.200 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (luangruo[at]yahoo.com) 1.6 SUBJ_LACKS_WORDS Subject is not short yet lacks words -0.0 T_SCC_BODY_TEXT_LINE No description available. X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Eli Zaretskii writes: > Unrelated to the problem of the MinGW build, the fact that > exec/configure.ac is not modified by admin/admin.el:set-version is a > bug, don't you agree? We should have 30.0.90 in that file, not > 30.0.50, right? Yes I do. I think I'll make this so tomorrow. From unknown Sat Aug 16 13:47:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73159: 30.0.90; uniscribe / harfbuzz are not initialized on Windows, resulting in fallback to gdi Resent-From: Casey Banner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Sep 2024 18:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 73159@debbugs.gnu.org Received: via spool by 73159-submit@debbugs.gnu.org id=B73159.172599315512370 (code B ref 73159); Tue, 10 Sep 2024 18:33:01 +0000 Received: (at 73159) by debbugs.gnu.org; 10 Sep 2024 18:32:35 +0000 Received: from localhost ([127.0.0.1]:37008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so5fH-0003DR-2k for submit@debbugs.gnu.org; Tue, 10 Sep 2024 14:32:35 -0400 Received: from mail-pg1-f180.google.com ([209.85.215.180]:56336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so5fE-0003DB-LD for 73159@debbugs.gnu.org; Tue, 10 Sep 2024 14:32:33 -0400 Received: by mail-pg1-f180.google.com with SMTP id 41be03b00d2f7-7d50b3a924bso1774997a12.0 for <73159@debbugs.gnu.org>; Tue, 10 Sep 2024 11:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725993081; x=1726597881; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PKDd81/YkRa8VKWsKtftc10Q2ZhVe3zm5ocQgwExzKQ=; b=NJ1roUbEePJwm4t6OZRCvFOgBb6nkN0De39sVt/zw4gBZUVxUmkF1HnKZVg0nPtn47 QiKbCQpPfENSVHw4B80cgboxFi/yzwzHR1UWABXEI4SPLbqx5NSgduTAgL02KNPDM/0W i/rTVgNwYfFvIpmDIy8+tZxqQALy3n2nbgvEu1GxM+0qEYIuckvDjwxSlZ24ds7wsGBR ucqSs7TpZNTeOGeE9ovgnhWFiptf+49259/K3PW1vDUXOIq5ED8KCO3Ku5mm5HIkOta2 szXHOsaHYp6KZPf27e0J6Wa11RCfPS0DvknNOkY0w+mIGfaOMzzrIF0n+QgQlsOFET7R WUMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725993081; x=1726597881; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PKDd81/YkRa8VKWsKtftc10Q2ZhVe3zm5ocQgwExzKQ=; b=wCE7o0xKp6y5vQ9fnkvTbo6e21rmi9XLYJv77gTkc7+Pp/ECO7iJ1hHPQqbXdoGNIE Pj1cB5ePqLJXykhmWWeFzY0YBFMIaMRWaETcp+E8wfg+lj1bI9dqd1feEZEp8Wot/LmJ eOGd9lomHXIPam4FvKUrQSbvMvW4gF6/Xip5BOF9mRUSQIpGi+wd9YCiQcKAsbNvxa0K ZCXsjVbZHHM231qDb5LdCrhs3x/LuraKGz+IrqRpdfsYiL5vCMr+3PapW5lSKvIZtGIY SwLAdWVdBJQNgYOig7oW0EvizFXAUnEOM9JoIOEjtjgDeJoksjpi+otMsx9JE2in34Uq quTQ== X-Gm-Message-State: AOJu0Yx9gWOiiYJIQ2waD6IDk0pGA0RwK7nasOVXS3QGst3BLu9bAt2x 7hO+IUr3gZM+FDOqzlruQGVT0UgjH+SPJ2z0omku7n1uJ4iBTJAmm5TDa1SKSIKlO7gXa2OWCXu mub2K0JHZQ01UQ+oncM87Di7cqI8= X-Google-Smtp-Source: AGHT+IHjVVSjdkfgEKFKt3UR0FMzXOG4gcyDiSGsLB5PO1duDKB/HVINSopMLKE3gTFijxhd9+zxIp+KODWykshNI0U= X-Received: by 2002:a05:6a21:39a:b0:1cf:2aaf:6d7a with SMTP id adf61e73a8af0-1cf5e08f724mr1828910637.17.1725993080793; Tue, 10 Sep 2024 11:31:20 -0700 (PDT) MIME-Version: 1.0 References: <867cbjvgby.fsf@gnu.org> In-Reply-To: <867cbjvgby.fsf@gnu.org> From: Casey Banner Date: Tue, 10 Sep 2024 14:31:07 -0400 Message-ID: Content-Type: multipart/alternative; boundary="0000000000007734a40621c814e6" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000007734a40621c814e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > How come your LANG is set to en_US.UTF-8? Did you set this in the > environment or something. Using UTF-8 as the default encoding on > Windows is not a good idea. It seems that the msys2 .profile has `export LANG=3D$(locale -uU)`, and tha= t returns en_US.UTF-8 for me. > Please look at src/epaths.h and see how PATH_EXEC is defined there. It is indeed #define PATH_EXEC "%emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32" src/epaths.in has #define PATH_EXEC "/usr/local/libexec/emacs" I had been running configure and make in a subdirectory. If I run them in the top-level directory, then it does update PATH_EXEC to the correct version. I think I made the wrong assumption that running configure in a subdirectory would leave the main source clean. Thank you for your help debugging this! - Casey On Tue, Sep 10, 2024 at 8:33=E2=80=AFAM Eli Zaretskii wrote: > > From: Casey Banner > > Date: Tue, 10 Sep 2024 01:50:43 -0400 > > > > I did a procmon dump to see what .pdmp files emacs.exe is trying to > load, and it attempts these locations: > > > > - E:\dev\emacs-src\bin\emacs.pdmp > > - > > > E:\dev\emacs-src\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs-ef314e5e0= 5618ae9e98f9cccc0769b2adce721d1b3bac00e305e61b4d457b0a4.pdmp > > > > - E:\dev\emacs-src\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs.pdmp > > > > The thing is, the emacs version is 30.0.90, not 30.0.50. > > > > A strings dump of emacs.exe: > > > > strings emacs.exe | grep 30.0 > > %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32 > > $Id: GNU Emacs 30.0.90 (x86_64-w64-mingw32 ACL GIF GMP GNUTLS HARFBUZZ > JPEG LCMS2 LIBXML2 > > MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 > THREADS TIFF > > TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB) $ > > 30.0.90 > > %emacs_dir%/share/emacs/30.0.90/lisp > > > %emacs_dir%/share/emacs/30.0.90/site-lisp;%emacs_dir%/share/emacs/site-li= sp > > /30.0.90/lisp/ > > %emacs_dir%/share/emacs/30.0.90/etc > > %emacs_dir%/libexec/emacs/30.0.90/x86_64-w64-mingw32 > > %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32 > > > > So it seems something is going wrong with setting the path. I noticed > that exec/configure.ac has: > > > > AC_INIT([libexec], [30.0.50], [bug-gnu-emacs@gnu.org], [], > > [https://www.gnu.org/software/emacs/]) > > exec/configure.ac is not used in the MinGW build (but the above is a > bug nonetheless, so I will fix it shortly). > > I cannot reproduce this result: > > > strings emacs.exe | grep 30.0 > > %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32 > > Please look at src/epaths.h and see how PATH_EXEC is defined there. > > > I tried changing this to 30.0.90 and re-building (using make bootstrap)= , > but the resulting binary still has 30.0.50 > > in it. > > As expected: the MinGW build doesn't use that file. You should > regenerate or update src/epaths.h. Perhaps touch src/epaths.in and > then re-run "make" in the top-level directory of the source tree. > > --0000000000007734a40621c814e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> How come your LANG is set to en_US.U= TF-8?=C2=A0 Did you set this in the
> environment or something.=C2=A0 Using UTF-8 as the default encoding on=
> Windows is not a good idea.

It se= ems that the msys2 .profile has `export LANG=3D$(locale -uU)`, and that ret= urns en_US.UTF-8 for me.

>=20 Please look at src/epaths.h and see how PATH_EXEC is defined there.

It is indeed=C2=A0 #define PATH_EXEC "%emacs_di= r%/libexec/emacs/30.0.50/x86_64-w64-mingw32"

src/epaths.in has #define PATH_EXEC "/usr/local/libexec= /emacs"

I had been running configure and make in a subdir= ectory. If I run them in the top-level directory,=C2=A0
then it d= oes update PATH_EXEC to the correct version. I think I made the wrong assum= ption that
=C2=A0running configure in a subdirectory would leave = the main source clean.

Thank you for your help= debugging this!

- Casey

<= div class=3D"gmail_quote">
On Tue, Sep= 10, 2024 at 8:33=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Casey Banner <kcbanner@gmail.com>
> Date: Tue, 10 Sep 2024 01:50:43 -0400
>
> I did a procmon dump to see what .pdmp files emacs.exe is trying to lo= ad, and it attempts these locations:
>
> - E:\dev\emacs-src\bin\emacs.pdmp
> -
> E:\dev\emacs-src\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs-ef314e= 5e05618ae9e98f9cccc0769b2adce721d1b3bac00e305e61b4d457b0a4.pdmp
>
> - E:\dev\emacs-src\libexec\emacs\30.0.50\x86_64-w64-mingw32\emacs.pdmp=
>
> The thing is, the emacs version is 30.0.90, not 30.0.50.
>
> A strings dump of emacs.exe:
>
> strings emacs.exe | grep 30.0
> %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32
> $Id: GNU Emacs 30.0.90 (x86_64-w64-mingw32 ACL GIF GMP GNUTLS HARFBUZZ= JPEG LCMS2 LIBXML2
> MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 TH= READS TIFF
> TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB) $
> 30.0.90
> %emacs_dir%/share/emacs/30.0.90/lisp
> %emacs_dir%/share/emacs/30.0.90/site-lisp;%emacs_dir%/share/emacs/site= -lisp
> /30.0.90/lisp/
> %emacs_dir%/share/emacs/30.0.90/etc
> %emacs_dir%/libexec/emacs/30.0.90/x86_64-w64-mingw32
> %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32
>
> So it seems something is going wrong with setting the path. I noticed = that exec/configure.ac has:
>
> AC_INIT([libexec], [30.0.50], [bug-gnu-emacs@gnu.org], [],
>=C2=A0 =C2=A0[https://www.gnu.org/software/emacs/])

exec/c= onfigure.ac is not used in the MinGW build (but the above is a
bug nonetheless, so I will fix it shortly).

I cannot reproduce this result:

> strings emacs.exe | grep 30.0
> %emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32

Please look at src/epaths.h and see how PATH_EXEC is defined there.

> I tried changing this to 30.0.90 and re-building (using make bootstrap= ), but the resulting binary still has 30.0.50
> in it.

As expected: the MinGW build doesn't use that file.=C2=A0 You should regenerate or update src/epaths.h.=C2=A0 Perhaps touch src/epaths.in and
then re-run "make" in the top-level directory of the source tree.=

--0000000000007734a40621c814e6-- From unknown Sat Aug 16 13:47:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73159: 30.0.90; uniscribe / harfbuzz are not initialized on Windows, resulting in fallback to gdi Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Sep 2024 18:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Casey Banner Cc: 73159@debbugs.gnu.org Received: via spool by 73159-submit@debbugs.gnu.org id=B73159.172599419415720 (code B ref 73159); Tue, 10 Sep 2024 18:50:01 +0000 Received: (at 73159) by debbugs.gnu.org; 10 Sep 2024 18:49:54 +0000 Received: from localhost ([127.0.0.1]:37027 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so5w2-00045U-4p for submit@debbugs.gnu.org; Tue, 10 Sep 2024 14:49:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49478) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so5vz-00045A-Gn for 73159@debbugs.gnu.org; Tue, 10 Sep 2024 14:49:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1so5ti-0003Ka-1m; Tue, 10 Sep 2024 14:47:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=pOpXBjKhcYlPgGIfSnDl9U1/yZP5YR/9RHuSUBYdpCI=; b=qvqvFDxOMmJI ihz641iP79r4xjiliedqPWb6CTVNOh+VDe+gkoLlcZ/sTGlgTRcgpXS0pZV4jsHUY6nLS0jZ3Sxf9 jnNU07EqkyTqeXtjz42L2fT50VFEvWYmXdJZNSM5Azlh+kRG6t2oOnJ4p6kBY80QGIXtRW5qnJxw8 gSEvyqm/5VAOxwoGOe59LdOmnfsbUn1rTwgE+VcdBtwfSug09Cy0glJzYUwD+ZI9coKDRs6Nw50l5 pfUmk0mu0hznFTE5EzcAte8oB6wH4I3AnAeEmgQeBijZEY4j4nBwueHUysLCZUrLF3ymLGGQt9M/N 0XMYWVJU9Pz1HXto3oN9FQ==; Date: Tue, 10 Sep 2024 21:47:13 +0300 Message-Id: <86jzfjtkge.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Casey Banner on Tue, 10 Sep 2024 14:31:07 -0400) References: <867cbjvgby.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Casey Banner > Date: Tue, 10 Sep 2024 14:31:07 -0400 > Cc: 73159@debbugs.gnu.org > > > How come your LANG is set to en_US.UTF-8? Did you set this in the > > environment or something. Using UTF-8 as the default encoding on > > Windows is not a good idea. > > It seems that the msys2 .profile has `export LANG=$(locale -uU)`, and that returns en_US.UTF-8 for me. I don't recommend running Emacs from the MSYS2 Bash prompt. Instead, run it from a desktop shortcut or pin it to the task bar and run from there. > > Please look at src/epaths.h and see how PATH_EXEC is defined there. > > It is indeed #define PATH_EXEC "%emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32" > > src/epaths.in has #define PATH_EXEC "/usr/local/libexec/emacs" > > I had been running configure and make in a subdirectory. If I run them in the top-level directory, > then it does update PATH_EXEC to the correct version. I think I made the wrong assumption that > running configure in a subdirectory would leave the main source clean. > > Thank you for your help debugging this! OK, so that's one mystery down. We are left with the HarfBuzz issue; please answer the questions I asked about that. From unknown Sat Aug 16 13:47:54 2025 X-Loop: help-debbugs@gnu.org Subject: bug#73159: Fwd: bug#73159: 30.0.90; uniscribe / harfbuzz are not initialized on Windows, resulting in fallback to gdi Resent-From: Casey Banner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Sep 2024 18:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 73159@debbugs.gnu.org Received: via spool by 73159-submit@debbugs.gnu.org id=B73159.172599467617560 (code B ref 73159); Tue, 10 Sep 2024 18:58:01 +0000 Received: (at 73159) by debbugs.gnu.org; 10 Sep 2024 18:57:56 +0000 Received: from localhost ([127.0.0.1]:37047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so63n-0004Z9-Mk for submit@debbugs.gnu.org; Tue, 10 Sep 2024 14:57:56 -0400 Received: from mail-pg1-f174.google.com ([209.85.215.174]:49610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so63l-0004Yw-LF for 73159@debbugs.gnu.org; Tue, 10 Sep 2024 14:57:54 -0400 Received: by mail-pg1-f174.google.com with SMTP id 41be03b00d2f7-7ae3d7222d4so905111a12.3 for <73159@debbugs.gnu.org>; Tue, 10 Sep 2024 11:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725994602; x=1726599402; darn=debbugs.gnu.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=TnHl5Pnif2Gj+8jyijcUmrDOAobrE/WnTYbF8IYYcqQ=; b=TvKAUj60NmL341QilS/AFpCWEol8uCNfKo6qFgNxaW8W6WVpIglh0uqYjoTFbNeD6+ YSp6KodzZ5sP7NqEHKwl5K1W4fryrkgVo8mMx3Ks5oQlD48PGT3WeM2CqE12aBZxhrus jRKlcPKA8ZjPz49Pw1aTgcMAXzEUa5RP3u8ORxq92yugG7/fS7PrpRucK4EpRaXh0big a0w55ZReWOeHFrnYSBiiX3C0K/qabKyYxmoySa3i82gtqyRQmn/oHT9H1JRAFyahGIhJ tWmJG5/mu1ZMuCYGI0KDwM//1iNGR80V0iEC0nngaCI1eWBZOkV4Ei0AeickyW4wmyUY 64yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725994602; x=1726599402; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TnHl5Pnif2Gj+8jyijcUmrDOAobrE/WnTYbF8IYYcqQ=; b=FiJmetreSK55hNxSb2CiHTo9qu4vwDEbCIUbJURm8kS7f1tfVoLgz8C6hAg0W92T7Z 0j8zdDUqyvvYd+EOJIGjfVW0kVIsP1Ef2CuZob9IKKNpV861XugXXy7k2sXRpCSqKLgL VNKqpFyA6C2Rc9AukLVkvLjsGGDKClWLMx8G1ZbgAX/+WK3t+6yIewABjYoKvgfA606P zlmKsAOliI16+I9Bpg7xUTJuuWevh9DITwuBSsf0MCtnWeJzcWemImfqKHtO/GuILJdg aQHT2dz6ouEOPdwXHzLTnpZwyvFg+NhyIQo7eF27QRWOw9/h+OC54wkyovTuQad12nT+ LHsQ== X-Gm-Message-State: AOJu0YzDSqbm/28ww+bFV90kviCs+5snjrBSkCIE5QTDufwQ1Yim5uG0 boCw0wkFtKQkCHKngH+s7gh2BgZDYPb4jTJQ2eH8jX9tzYPyg1i6mz9j7CqwrdTT7oqs1vr/nAg mhCg1H7Xft6QEAW3CXOnnZeCiQbN7pA== X-Google-Smtp-Source: AGHT+IGNyEuTRTdhhKwunsuUM367pMKabrLaCilr386vAF7Hi4xXB/i0SlsyAhqSBJSSqd77pd2bGVqWC6ie9A1nnuk= X-Received: by 2002:a05:6a20:b598:b0:1cf:314d:4ff1 with SMTP id adf61e73a8af0-1cf62ce9328mr1076809637.30.1725994601718; Tue, 10 Sep 2024 11:56:41 -0700 (PDT) MIME-Version: 1.0 References: <867cbjvgby.fsf@gnu.org> <86jzfjtkge.fsf@gnu.org> In-Reply-To: From: Casey Banner Date: Tue, 10 Sep 2024 14:56:28 -0400 Message-ID: Content-Type: multipart/alternative; boundary="0000000000001eac0d0621c86fbc" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000001eac0d0621c86fbc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > OK, so that's one mystery down. We are left with the HarfBuzz issue; > please answer the questions I asked about that. Ah, yes sorry - I acquired the DLLs from the mingw64/mingw-w64-x86_64-harfbuzz package. $ objdump -x /mingw64/bin/libharfbuzz-0.dll | grep "DLL Name": DLL Name: libgcc_s_seh-1.dll DLL Name: GDI32.dll DLL Name: KERNEL32.dll DLL Name: msvcrt.dll DLL Name: RPCRT4.dll DLL Name: libstdc++-6.dll DLL Name: USER32.dll DLL Name: USP10.dll DLL Name: libfreetype-6.dll DLL Name: libglib-2.0-0.dll DLL Name: libgraphite2.dll DLL Name: libintl-8.dll harfbuzz does load correctly now that the pdmp is being loaded correctly - I believe because now it passes the `intialized` check and so actually attempts to load them. describe-char shows me: harfbuzz:-outline-Iosevka Fixed SS02-regular-normal-normal-mono-14-*-*-*-c-*-iso8859-1 (#x56) On Tue, Sep 10, 2024 at 2:47=E2=80=AFPM Eli Zaretskii wrote: > > From: Casey Banner > > Date: Tue, 10 Sep 2024 14:31:07 -0400 > > Cc: 73159@debbugs.gnu.org > > > > > How come your LANG is set to en_US.UTF-8? Did you set this in the > > > environment or something. Using UTF-8 as the default encoding on > > > Windows is not a good idea. > > > > It seems that the msys2 .profile has `export LANG=3D$(locale -uU)`, and > that returns en_US.UTF-8 for me. > > I don't recommend running Emacs from the MSYS2 Bash prompt. Instead, > run it from a desktop shortcut or pin it to the task bar and run from > there. > > > > Please look at src/epaths.h and see how PATH_EXEC is defined there. > > > > It is indeed #define PATH_EXEC > "%emacs_dir%/libexec/emacs/30.0.50/x86_64-w64-mingw32" > > > > src/epaths.in has #define PATH_EXEC "/usr/local/libexec/emacs" > > > > I had been running configure and make in a subdirectory. If I run them > in the top-level directory, > > then it does update PATH_EXEC to the correct version. I think I made th= e > wrong assumption that > > running configure in a subdirectory would leave the main source clean. > > > > Thank you for your help debugging this! > > OK, so that's one mystery down. We are left with the HarfBuzz issue; > please answer the questions I asked about that. > --0000000000001eac0d0621c86fbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> OK, so that's one mystery down.=C2=A0 We are left with the Harf= Buzz issue;
> please answer the questions I asked about that.

Ah, yes sorry -=C2=A0 I acquired the DLLs from = the mingw64/mingw-w64-x86_64-harfbuzz package.

$ o= bjdump -x /mingw64/bin/libharfbuzz-0.dll | grep "DLL Name":
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 DLL Name: libgcc_s_seh-1.dll
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 DLL Name: GDI32.dll
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DLL Name: = KERNEL32.dll
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DLL Name: msvcrt.dll
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 DLL Name: RPCRT4.dll
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DL= L Name: libstdc++-6.dll
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DLL Name: USER32.dll=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DLL Name: USP10.dll
=C2=A0 =C2=A0 =C2=A0= =C2=A0 DLL Name: libfreetype-6.dll
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DLL Name= : libglib-2.0-0.dll
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DLL Name: libgraphite2.d= ll
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DLL Name: libintl-8.dll

harfbuzz does load correctly now that the pdmp is being loaded corr= ectly - I believe because now it passes the `intialized` check and so actua= lly attempts to load them.

describe-char shows me:= harfbuzz:-outline-Iosevka Fixed SS02-regular-normal-normal-mono-14-*-*-*-c= -*-iso8859-1 (#x56)

On Tue, Sep 10, 2024 at 2:47=E2=80=AFPM= Eli Zaretskii <eliz@g= nu.org> wrote:
> From: Casey Banner <kcbanner@gmail.com>
> Date: Tue, 10 Sep 2024 14:31:07 -0400
> Cc: 73159@d= ebbugs.gnu.org
>
> > How come your LANG is set to en_US.UTF-8?=C2=A0 Did you set this = in the
> > environment or something.=C2=A0 Using UTF-8 as the default encodi= ng on
> > Windows is not a good idea.
>
> It seems that the msys2 .profile has `export LANG=3D$(locale -uU)`, an= d that returns en_US.UTF-8 for me.

I don't recommend running Emacs from the MSYS2 Bash prompt.=C2=A0 Inste= ad,
run it from a desktop shortcut or pin it to the task bar and run from
there.

> > Please look at src/epaths.h and see how PATH_EXEC is defined ther= e.
>
> It is indeed=C2=A0 #define PATH_EXEC "%emacs_dir%/libexec/emacs/3= 0.0.50/x86_64-w64-mingw32"
>
> src/= epaths.in has #define PATH_EXEC "/usr/local/libexec/emacs" >
> I had been running configure and make in a subdirectory. If I run them= in the top-level directory,
> then it does update PATH_EXEC to the correct version. I think I made t= he wrong assumption that
>=C2=A0 running configure in a subdirectory would leave the main source = clean.
>
> Thank you for your help debugging this!

OK, so that's one mystery down.=C2=A0 We are left with the HarfBuzz iss= ue;
please answer the questions I asked about that.
--0000000000001eac0d0621c86fbc-- From unknown Sat Aug 16 13:47:54 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Casey Banner Subject: bug#73159: closed (Re: bug#73159: 30.0.90; uniscribe / harfbuzz are not initialized on Windows, resulting in fallback to gdi) Message-ID: References: <86ikv3sz8w.fsf@gnu.org> X-Gnu-PR-Message: they-closed 73159 X-Gnu-PR-Package: emacs Reply-To: 73159@debbugs.gnu.org Date: Wed, 11 Sep 2024 02:28:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1726021682-7641-1" This is a multi-part message in MIME format... ------------=_1726021682-7641-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #73159: 30.0.90; uniscribe / harfbuzz are not initialized on Windows, resul= ting in fallback to gdi which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 73159@debbugs.gnu.org. --=20 73159: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D73159 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1726021682-7641-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 73159-done) by debbugs.gnu.org; 11 Sep 2024 02:27:45 +0000 Received: from localhost ([127.0.0.1]:37279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soD57-0001yk-CQ for submit@debbugs.gnu.org; Tue, 10 Sep 2024 22:27:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soD54-0001yT-Qx for 73159-done@debbugs.gnu.org; Tue, 10 Sep 2024 22:27:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1soD2m-0002Wx-Nf; Tue, 10 Sep 2024 22:25:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=CbLSy5pWxHn/OsEXAswG2G6XWwfAbsfpyWhx9xFeaiE=; b=a1ZkYnjHo0Do /XG1I2HvI9bWGqCBfnIsi0GjPfxR6ufrO6coLVYLdMI4AzRTCXE1hPl3ZqpDERVqg4wVsRqsJMTTU MX12VhfGfQOEudRYAq3VTBXhjBXGted1xTwNb4Cj0mrF9KLVZLM1NhQJdZgSK3676biMHeMjAUj6M OdbNNTTzap4Dwm6CBAD+iGpn6DQUJepS4rk+svjcZggHTeF4iOkfg9n3X//RVmj6cmCnZ7LIjqf7h 1oVCUmdLW7fea7hZ3Jp9ByOiOd4SUf674ku+kc+h2TA4g8qdggi9G59w498SccFVGYisTAquYwDwQ 5wGlL1LiU/474fvqDzhfFA==; Date: Wed, 11 Sep 2024 05:25:19 +0300 Message-Id: <86ikv3sz8w.fsf@gnu.org> From: Eli Zaretskii To: Casey Banner In-Reply-To: (message from Casey Banner on Tue, 10 Sep 2024 14:56:28 -0400) Subject: Re: bug#73159: 30.0.90; uniscribe / harfbuzz are not initialized on Windows, resulting in fallback to gdi References: <867cbjvgby.fsf@gnu.org> <86jzfjtkge.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73159-done Cc: 73159-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Casey Banner > Date: Tue, 10 Sep 2024 14:56:28 -0400 > > > OK, so that's one mystery down. We are left with the HarfBuzz issue; > > please answer the questions I asked about that. > > Ah, yes sorry - I acquired the DLLs from the mingw64/mingw-w64-x86_64-harfbuzz package. > > $ objdump -x /mingw64/bin/libharfbuzz-0.dll | grep "DLL Name": > DLL Name: libgcc_s_seh-1.dll > DLL Name: GDI32.dll > DLL Name: KERNEL32.dll > DLL Name: msvcrt.dll > DLL Name: RPCRT4.dll > DLL Name: libstdc++-6.dll > DLL Name: USER32.dll > DLL Name: USP10.dll > DLL Name: libfreetype-6.dll > DLL Name: libglib-2.0-0.dll > DLL Name: libgraphite2.dll > DLL Name: libintl-8.dll > > harfbuzz does load correctly now that the pdmp is being loaded correctly - I believe because now it passes the > `intialized` check and so actually attempts to load them. > > describe-char shows me: harfbuzz:-outline-Iosevka Fixed > SS02-regular-normal-normal-mono-14-*-*-*-c-*-iso8859-1 (#x56) OK, so I'm now closing this bug. ------------=_1726021682-7641-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 10 Sep 2024 04:15:50 +0000 Received: from localhost ([127.0.0.1]:34508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snsI9-0000mL-8N for submit@debbugs.gnu.org; Tue, 10 Sep 2024 00:15:50 -0400 Received: from lists.gnu.org ([209.51.188.17]:41802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1snsI6-0000mC-NL for submit@debbugs.gnu.org; Tue, 10 Sep 2024 00:15:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1snsI2-0005yS-1U for bug-gnu-emacs@gnu.org; Tue, 10 Sep 2024 00:15:42 -0400 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1snsHz-000860-N3 for bug-gnu-emacs@gnu.org; Tue, 10 Sep 2024 00:15:41 -0400 Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-717914d6c95so3303737b3a.0 for ; Mon, 09 Sep 2024 21:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725941737; x=1726546537; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=WYPi5FHCJSUwOmQh0HYiPjE7U+zh0EeZlhz1T7Dd97I=; b=LUkgHpMA+byqDnJ8ov3JWDtgMXQy9CDVLeEs35WFlWmolv69pIpPF3F7kwkS/deVHC SxmNGH0+JtWDb/CO2S4+k6PHBqhI3ti6Ev+SXWi6VVwkUCxfOEwmY0yJN+S/VUjYZU/J eBBXoUomqARjDBqT1YT79QiIiiVXqMdk1mXlzuPcJBU4bxkx64lIIbA2igtBNBQOJnkv yX98681Bp3TkUnlJ7o3xOaY/Zr3YVbQB7X4vlNsUCDrdzkfioV0Lcr5+d9jCCGER9ZiE i1c3i4bC2ZxVmKppISWAvhV/6wGGJbNRCpCpEz3OIOgL1PAMQKGNS0K6tKY7V004MzJe FmyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725941737; x=1726546537; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=WYPi5FHCJSUwOmQh0HYiPjE7U+zh0EeZlhz1T7Dd97I=; b=IXitvYG1wzgMoWPLkccr/TR721WvA9/UfGM6PLB10JJPJV0vLfos7WdfvJqKvzqOBz ggdP+fqXhpmzpZcrEOq05Lq/Z1OucbjbyCOK6yw3GtNKe6anOde5CvRNE8oJmvyiK40W coMRZsTHA05M4pDBGUL/yba/bEI0rhZZEH+2jOCSHDiQQU/dBkUps+0cULJjziLKfmaK Q/ULihzejihb8O/+iGRz0au0KLi61FBiqIVM89dVmwt+9E1XIVPEvroknUIhWa8CpaEo QGD3dM4YJBTu0jveyGTewFaIjBB4dkj7T846CVFebOPLcfUeExUE907x7i2O9HIyi6bd xTow== X-Gm-Message-State: AOJu0YzSb/sVK9wYIHt67SwNW16rgRsk/Pkf+qQubwQ98XqJ/244jEmm aV9U3Z4VMBLQjufyOSCvaEps/YKHR7wNcIdrGL6teTqqWjDMzCVM5HsMs7mSyYVZ1rijXcpl5Ra 5VWQkeuKElck1wtjHna3Xzv2JtxPr4pfZ X-Google-Smtp-Source: AGHT+IGrQ+lkVu9KpupTgOnWWyKK0F2sOiRFy0xaixJDf4P/Rt4JyGncrgbBM+rmz9vQNl24DCTzIizGeiCp5QaOA3k= X-Received: by 2002:a05:6a21:6b0b:b0:1cf:4c70:f26f with SMTP id adf61e73a8af0-1cf4c70f4b2mr2963359637.17.1725941736649; Mon, 09 Sep 2024 21:15:36 -0700 (PDT) MIME-Version: 1.0 From: Casey Banner Date: Tue, 10 Sep 2024 00:15:24 -0400 Message-ID: Subject: 30.0.90; uniscribe / harfbuzz are not initialized on Windows, resulting in fallback to gdi To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="0000000000001dbf2a0621bc209b" Received-SPF: pass client-ip=2607:f8b0:4864:20::42e; envelope-from=kcbanner@gmail.com; helo=mail-pf1-x42e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --0000000000001dbf2a0621bc209b Content-Type: text/plain; charset="UTF-8" I recently pulled the latest emacs-30 branch (f47297782bdb5e5a07e02f119c8013d11f7d7fae), and I'm building emacs using MSYS2 mingw64 on Windows. With a build on this branch, certain symbols (from the nerd-icons package) were rendering as boxes and not their actual symbol. I suspected that this was because gdi was being used, and indeed using describe-char on any character shows me a font starting with `gdi:`, indicating the uniscribe or harfbuzz are not being used. This is not the case on the emacs-29 branch, where I see `uniscribe:` instead (and the symbols render correctly). I was not able to get harfbuzz to load on that branch, which is why I was trying emacs-30 to see if something was different there. To investigate this, I first used procmon to look at the syscalls to see if anything was trying to load libharfbuzz-0.dll, and I did see it in the trace I took, however the callstack was an OS callstack, and not from where I expected (src\w32uniscribe.c:syms_of_w32uniscribe_for_pdumber). I rebuilt with debug symbols, and set a breakpoint in that function - it was called once, but `initialized` was false so the LoadLibrary calls never ran. I'm not too familiar with how pdumper works, or the emacs source in general, so I'm not sure what the actual root cause is here. I did a bit more debugging to see when `initialized` was set to true, and it does get set later during initialization. I noted that I do not have a .pdmp file in my installation direction, which it seems to be trying to load during startup. One more piece of information: attempting to yank any text results in the error: `Coding system is invalid or doesn't have an eol variant for dos line ends: nil` This error occurs when starting with -Q and attempting to yank any text. If I call `(set-selection-coding-system 'utf-16-le)`, it resolves the issue. However, I didn't have to do this in emacs-29, so this makes me think something has possibly broken with init on Windows, since I believe this is not supposed to be nil by default? I'm happy to assist by providing any additional info if needed! Thanks, Casey In GNU Emacs 30.0.90 (build 1, x86_64-w64-mingw32) of 2024-09-09 built on DESKTOP-EK25TL1 Windowing system distributor 'Microsoft Corp.', version 10.0.19045 System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.4780) Configured using: 'configure -prefix=/e/dev/emacs-src --without-dbus --without-pop --with-native-compilation --with-wide-int --without-compress-install --with-json --with-tree-sitter --without-imagemagick 'CFLAGS=-O2 -mtune=native -march=native -fomit-frame-pointer -ftree-vectorize -Wno-error=implicit-function-declaration -pipe -g' PKG_CONFIG_PATH=/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB (NATIVE_COMP present but libgccjit not available) Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: cp1252 Major mode: Fundamental Minor modes in effect: tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cus-start cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel touch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process native-compile emacs) Memory information: ((conses 16 181417 72491) (symbols 48 21836 0) (strings 32 65423 2126) (string-bytes 1 4014620) (vectors 16 34658) (vector-slots 8 1231317 136112) (floats 8 196 11) (intervals 56 408 0) (buffers 992 11)) --0000000000001dbf2a0621bc209b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I recently pulled the latest emacs-30 branch (f472977= 82bdb5e5a07e02f119c8013d11f7d7fae),=C2=A0
and I'm building em= acs using MSYS2 mingw64 on Windows.

With a build on this branch, c= ertain symbols (from the nerd-icons
package) were rendering as boxes and= not their actual symbol. I
suspected that this was because gdi was bein= g used, and indeed using
describe-char on any character shows me a font = starting with
`gdi:`, indicating the uniscribe or harfbuzz are not being= used.

This is not the case on the emacs-29 branch, where I see `uni= scribe:`
instead (and the symbols render correctly). I was not able to g= et
harfbuzz to load on that branch, which is why I was trying emacs-30to see if something was different there.

To investigate this, I fi= rst used procmon to look at the syscalls to
see if anything was trying t= o load libharfbuzz-0.dll, and I did see it
in the trace I took, however = the callstack was an OS callstack, and not
from where I expected (src\w3= 2uniscribe.c:syms_of_w32uniscribe_for_pdumber).

I rebuilt with debug= symbols, and set a breakpoint in that function - it
was called once, bu= t `initialized` was false so the LoadLibrary calls
never ran. I'm no= t too familiar with how pdumper works, or the emacs
source in general, s= o I'm not sure what the actual root cause is here.

I did a bit m= ore debugging to see when `initialized` was set to true,
and it doe= s get set later during initialization. I noted that I do not have a .pdmp f= ile
in my installation direction, which it seems to be trying to = load during startup.

One more piece of information= : attempting to yank any text results in the error:

`Coding system is invalid or doesn't have an eol variant for dos line= ends: nil`

This error occurs when starting w= ith -Q and attempting to yank any text. If I=C2=A0
call `(set-sel= ection-coding-system 'utf-16-le)`, it resolves the issue.

However, I didn't have to do this in emacs-29, so this= makes me think=C2=A0
something has possibly broken with init on = Windows, since I believe this
is not supposed to be nil by defaul= t?

I'm happy to assist by providing any ad= ditional info if needed!

Thanks,
Casey

In GNU Emacs 30.0.90 (build 1, x86_64-w64-mingw32) of 2024-09-0= 9 built
=C2=A0on DESKTOP-EK25TL1
Windowing system distributor 'Mi= crosoft Corp.', version 10.0.19045
System Description: Microsoft Win= dows 10 Pro (v10.0.2009.19045.4780)

Configured using:
=C2=A0'= configure -prefix=3D/e/dev/emacs-src --without-dbus --without-pop
=C2=A0= --with-native-compilation --with-wide-int --without-compress-install
=C2= =A0--with-json --with-tree-sitter --without-imagemagick 'CFLAGS=3D-O2=C2=A0-mtune=3Dnative -march=3Dnative -fomit-frame-pointer -ftree-vectori= ze
=C2=A0-Wno-error=3Dimplicit-function-declaration -pipe -g'
=C2= =A0PKG_CONFIG_PATH=3D/mingw64/lib/pkgconfig:/mingw64/share/pkgconfig'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML= 2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 TH= READS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_= COMP present but libgccjit not available)

Important settings:
=C2= =A0 value of $LANG: en_US.UTF-8
=C2=A0 locale-coding-system: cp1252
<= br>Major mode: Fundamental

Minor modes in effect:
=C2=A0 tooltip-= mode: t
=C2=A0 global-eldoc-mode: t
=C2=A0 show-paren-mode: t
=C2= =A0 electric-indent-mode: t
=C2=A0 mouse-wheel-mode: t
=C2=A0 tool-ba= r-mode: t
=C2=A0 menu-bar-mode: t
=C2=A0 file-name-shadow-mode: t
= =C2=A0 global-font-lock-mode: t
=C2=A0 blink-cursor-mode: t
=C2=A0 mi= nibuffer-regexp-mode: t
=C2=A0 buffer-read-only: t
=C2=A0 line-number= -mode: t
=C2=A0 indent-tabs-mode: t
=C2=A0 transient-mark-mode: t
= =C2=A0 auto-composition-mode: t
=C2=A0 auto-encryption-mode: t
=C2=A0= auto-compression-mode: t

Load-path shadows:
None found.

F= eatures:
(shadow sort mail-extr emacsbug message mailcap yank-media puny= dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg = rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-de= code
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailhea= der
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
ma= il-prsvr mail-utils rmc iso-transl tooltip cus-start cconv eldoc paren
e= lectric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
t= ouch-screen dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
ter= m/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list= replace newcomment text-mode lisp-mode prog-mode register
page tab-bar = menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-= lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice= seq simple cl-generic indonesian philippine
cham georgian utf-8-lang mi= sc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp= 51932 hebrew greek romanian slovak czech
european ethiopic indian cyrill= ic chinese composite emoji-zwj charscript
charprop case-table epa-hook j= ka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs t= heme-loaddefs faces cus-face macroexp
files window text-properties overl= ay sha1 md5 base64 format env
code-pages mule custom widget keymap hasht= able-print-readable backquote
threads w32notify w32 lcms2 multi-tty move= -toolbar make-network-process
native-compile emacs)

Memory inform= ation:
((conses 16 181417 72491) (symbols 48 21836 0) (strings 32 65423 = 2126)
=C2=A0(string-bytes 1 4014620) (vectors 16 34658)
=C2=A0(vector= -slots 8 1231317 136112) (floats 8 196 11)
=C2=A0(intervals 56 408 0) (b= uffers 992 11))
--0000000000001dbf2a0621bc209b-- ------------=_1726021682-7641-1--