From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Casey Banner Newsgroups: gmane.emacs.bugs Subject: bug#73159: 30.0.90; uniscribe / harfbuzz are not initialized on Windows, resulting in fallback to gdi Date: Tue, 10 Sep 2024 14:31:07 -0400 Message-ID: References: <867cbjvgby.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007734a40621c814e6" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21561"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 73159@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 10 20:33:19 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1so5fz-0005RL-6N for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Sep 2024 20:33:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1so5fi-00052q-Hu; Tue, 10 Sep 2024 14:33:02 -0400 Original-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 1so5fd-00052V-Mr for bug-gnu-emacs@gnu.org; Tue, 10 Sep 2024 14:32:57 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1so5fd-0001lZ-Ej for bug-gnu-emacs@gnu.org; Tue, 10 Sep 2024 14:32:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=PKDd81/YkRa8VKWsKtftc10Q2ZhVe3zm5ocQgwExzKQ=; b=abLVFRut81DBH/7fbBXHnCP/XX62oD/OIGWVYYKVRj3/OB9v/auNYZqmk4ZhFYJDngb3PsWe+fI4Z42n0zaM23Rbbwc3By7Jn1wi9Yrl8l999/fAxLegJg1v89LQQJshfscknjZbv/xYDgdJNxZdQ+yl00dOE7SMy2ERdpm+A5RM6t9neOtMVGz98/mcIbT37zw+Ua8KiuEd+53+Nq4sGhkwlvChjfd3DIUKFXRFXziEvdGeOtx/vP5bMbVRIr0D8KFyWJ8A1/fE4I15il7jJlI66pv7AggY6gt6SqXmasFq/iOa34RQgvyUkWDzkFrqJV0Z0Si/oa34j0G9A9Fqmw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1so5fh-0003E9-Ph for bug-gnu-emacs@gnu.org; Tue, 10 Sep 2024 14:33:01 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 73159-submit@debbugs.gnu.org id=B73159.172599315512370 (code B ref 73159); Tue, 10 Sep 2024 18:33:01 +0000 Original-Received: (at 73159) by debbugs.gnu.org; 10 Sep 2024 18:32:35 +0000 Original-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 Original-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 Original-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) In-Reply-To: <867cbjvgby.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:291576 Archived-At: --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--