From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Windows port binaries Date: Wed, 16 Aug 2023 14:36:52 +0300 Message-ID: <83ttsz8bhn.fsf@gnu.org> References: <4536176.VaOIPsP7d9@nimes> <87zg2umnx8.fsf@yahoo.com> <3861918.kkAUEy7oZ9@nimes> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22109"; mail-complaints-to="usenet@ciao.gmane.io" Cc: corwin@bru.st, Emacs-devel@gnu.org, luangruo@yahoo.com, eggert@cs.ucla.edu To: Bruno Haible Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 16 13:37:50 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qWEqU-0005US-86 for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Aug 2023 13:37:50 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qWEpV-00043q-Pr; Wed, 16 Aug 2023 07:36:49 -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 1qWEpU-00043Y-EO for Emacs-devel@gnu.org; Wed, 16 Aug 2023 07:36:48 -0400 Original-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 1qWEpT-0002hG-8Y; Wed, 16 Aug 2023 07:36:47 -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=5RvxxydW6aQpMOvNYlj0Dy7uBmfLA9inkoX9DtTUses=; b=dZYYg2klhj3K k7U4n+MGwa6Gaphc6mBrivIibW5Uk/ACGn0kA8igrK3ocs68Ac7oAQMRKSWH2KjQ+HEa7t8m0GOIX 9mHRFszpcvAPQPpRjvRca2TUsHWwmy/dWEexceSTcafwuvWTYwxdocqSsJa1FB9RPlLlz689TNdRM ymkoDcX7T8HnYPPIKyLnUq9LlXJqnmUbTtThDyUBRGtFlBatVDToIK3ov6MaZjhQ0Ie/vAaMXp1e4 m40GzWbAYhXRUBTurU7sl2SXnri7ZUS4LyWDcMTeIc2IjIdxJ+vtbnB+gQU84XPAvVczHjCu5IOCN yQg6e5Hq8DmF1+q/66Z27w==; In-Reply-To: <3861918.kkAUEy7oZ9@nimes> (message from Bruno Haible on Tue, 15 Aug 2023 21:57:47 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308812 Archived-At: > From: Bruno Haible > Cc: Po Lu , Paul Eggert > Date: Tue, 15 Aug 2023 21:57:47 +0200 > > > https://corwin.bru.st/emacs-29 > > https://corwin.bru.st/emacs-30 > > Thanks. I tried to use the > https://corwin.bru.st/emacs-30/emacs-30-latest-no-deps.zip > binary from today, but they don't work for me (on Windows 10), because > they rely on two DLLs which are not contained in the 'bin' directory: > - libgmp-10.dll > - libwinpthread-1.dll libwinpthread-1.dll shouldn't be there. But maybe there's no way to avoid that with MinGW64 ports of GCC. See below. > Find below the output of "dumpbin.exe /imports emacs.exe". A more GNU-friendly way is objdump -p emacs.exe | fgrep "DLL Name:" > Additionally, I find it strange: > > 1) Why are the imports from libgmp all prefixed with '__'? That's > a bit unusual. Why are you asking us? The Emacs project doesn't build libgmp, it only uses it. This question shouldf go to the GMP developers, IMO. > 2) emacs/nt/mingw-cfg.site contains this comment: > # We don't want to check for these functions > # because they are implemented in libwinpthread. > corresponding to this ChangeLog entry: > > 2016-04-21 Fabrice Popineau > > Avoid run-time dependency on libwinpthread DLL on MS-Windows > > * nt/mingw-cfg.site (ac_cv_search_clock_gettime) > (ac_cv_func_clock_gettime, ac_cv_func_clock_settime): Force to not > present, so that MinGW64 builds don't depend on libwinpthread. > (Bug#22959) > > However, the binaries rely on nanosleep() from libwinpthread. > Is it intended or unintended? I guess this is some kind of regression. But I'm not sure we can avoid this, when MinGW64 is used. (I use mingw.org's MinGW, and my Emacs on Windows doesn't have the libwinpthread dependency.)