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: [feature/native-comp] breakage on build Date: Sat, 06 Feb 2021 15:45:51 +0200 Message-ID: <83ft29nwc0.fsf@gnu.org> References: <87lfca7lsb.fsf@russet.org.uk> <838s8a8adr.fsf@gnu.org> <83sg6h6s6d.fsf@gnu.org> <8335yf7qtf.fsf@gnu.org> <831rdy5i2r.fsf@gnu.org> <87y2g5p0q8.fsf@russet.org.uk> <87im7799s9.fsf@russet.org.uk> <87wnvn5yoz.fsf@russet.org.uk> <87eehuomn2.fsf@russet.org.uk> <83lfc2px16.fsf@gnu.org> <87czxe45f8.fsf@russet.org.uk> <8335yap6p8.fsf@gnu.org> <87wnvm2nhb.fsf@russet.org.uk> <83wnvlod0k.fsf@gnu.org> <87wnvlmjxo.fsf@russet.org.uk> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13762"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, akrl@sdf.org To: Phillip Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 06 14:47:44 2021 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 1l8Nw8-0003Ud-EO for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Feb 2021 14:47:44 +0100 Original-Received: from localhost ([::1]:36568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l8Nw7-0007hh-7q for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Feb 2021 08:47:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37172) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8NuU-0006Ta-LW for emacs-devel@gnu.org; Sat, 06 Feb 2021 08:46:03 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39317) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l8NuT-0008JO-Ss; Sat, 06 Feb 2021 08:46:01 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4710 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l8NuG-0003Yy-Gk; Sat, 06 Feb 2021 08:45:59 -0500 In-Reply-To: <87wnvlmjxo.fsf@russet.org.uk> (message from Phillip Lord on Sat, 06 Feb 2021 12:58:59 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:264065 Archived-At: > From: Phillip Lord > Cc: akrl@sdf.org, emacs-devel@gnu.org > Date: Sat, 06 Feb 2021 12:58:59 +0000 > > So, I did this: > > - Installed a fresh msys to a clean directory on my desktop. > - Dropped the emacs-no-deps.zip directory on top of the mingw64 directory. > - clicked on runemacs.exe from windows shell -- Emacs fails to launch > because of libgmp > - pacman installed all the dependencies of Emacs > - clicked on runemacs.exe -- Emacs launches, native-comp fails as > described Fails with exactly the same error messages? Even though now as.exe should be on PATH and GCC should be able to find it? > - run mingw64 shell form the mys installation > - ./runemacs.exe in that shell > - Emacs launches, native-comp works > - ~/ and thus ~/.emacs.d/eln-cache is a different location with the two > launch methods Please show the full environment as Emacs sees it (look in process-environment) both when it's launched from mingw64 shell and outside of it. > Conclusions: > > - emacs is picking up dependencies from mingw64 run in either way, > because otherwise it wouldn't run at all from the shell > - Emacs is picking up the environment from mingw64 when launched from > within it, hence the differences in location of ~ > - Native-comp has everything it needs to run, or it couldn't run at > all. > - It is missing something from the environment when run in the windows > shell. > > This is export run inside the mingw64 window. So, lots of options there. > [...] > declare -x MINGW_PREFIX="/mingw64" What is the meaning and the use of MINGW_PREFIX? > declare -x PATH="/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl" Could it be that Emacs when started from the mingw64 shell picks up GCC components from this PATH, and thus GCC will then look for the libraries and object files for native-comp in the "normal" mingw64 installation, not in the Emacs tree you created? In that case the fact that native-comp works from the mingw64 shell is not interesting, as ll it says that your duplicate GCC installation is somehow incomplete. I don't see any other variable that I think could be related. (But I don't use MinGW64, so I could miss something.) However, you show the exported variables from the MSYS Bash, whereas what we need to look at is the environment variables as seen by GCC, when it is run from Emacs. The value of process-environment in both cases should be a good first step.