From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dani Moncayo Newsgroups: gmane.emacs.devel Subject: Re: Bootstrap failure on MS-Windows Date: Tue, 5 Nov 2013 22:08:51 +0100 Message-ID: References: <134n7uab5v.fsf@fencepost.gnu.org> <83r4au7li4.fsf@gnu.org> <83mwli7gwq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1383685744 12960 80.91.229.3 (5 Nov 2013 21:09:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Nov 2013 21:09:04 +0000 (UTC) Cc: Emacs development discussions To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 05 22:09:09 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vdns3-0001ZY-00 for ged-emacs-devel@m.gmane.org; Tue, 05 Nov 2013 22:09:07 +0100 Original-Received: from localhost ([::1]:58508 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vdns2-0000xW-HS for ged-emacs-devel@m.gmane.org; Tue, 05 Nov 2013 16:09:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58400) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vdnrv-0000xO-Oo for emacs-devel@gnu.org; Tue, 05 Nov 2013 16:09:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vdnru-0002cC-7v for emacs-devel@gnu.org; Tue, 05 Nov 2013 16:08:59 -0500 Original-Received: from mail-lb0-x22a.google.com ([2a00:1450:4010:c04::22a]:50527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vdnrr-0002bL-17; Tue, 05 Nov 2013 16:08:55 -0500 Original-Received: by mail-lb0-f170.google.com with SMTP id u14so7139605lbd.1 for ; Tue, 05 Nov 2013 13:08:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ulyry7ZqnZGDkkeoTkLkzd9KztvrXFKDB9daI8cyr1k=; b=Cou3ZfJDqhM5Sj9eg8UN9cJ6YF5gE80olrHbpFT0+UqZliyO6EkCxB7mCzPn5x9n8o vmRhwchlAM6V6R/LMmTGbsA19E3QzTcpixX5z83iN1KBrss7Xp2Y7prC+s1/5SlIc45C HkEPdI+KIWj2cY0D7OPqK+ogmw3/fazbN7909qVu1pBh8+I4eYhwWHfgd/lmFAymKuGu BtddhZqXZvUfkEmIBJ8GSUYpqAsKtoaMBdR4DyJlUQ4IUVnxU36aZAO5eTJMlAMAwRb3 k5Y1RtMgEg5TcNdGm6SWWaYiRIsf/LtSQ53CKDdSLyPHazgDsC/LkhvPGppZJeAo/Jsv vf+A== X-Received: by 10.152.8.18 with SMTP id n18mr7563864laa.24.1383685732037; Tue, 05 Nov 2013 13:08:52 -0800 (PST) Original-Received: by 10.114.176.231 with HTTP; Tue, 5 Nov 2013 13:08:51 -0800 (PST) In-Reply-To: <83mwli7gwq.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164986 Archived-At: >> I've tried again with that correction, but I see the same failure. >> >> I may provide any necessary info to investigate this further (though I >> think that this problem should be trivial to reproduce by anyone who >> builds Emacs on MS-Windows). > > The relevant piece of information is src/epaths.h. But really, Dani, > you are the only person who is motivated enough to dig into this, so > please do. The issue cannot be too complicated: what happens here is > that Emacs does not find its lisp subdirectory, and therefore looks > for the one in the installation tree, which doesn't yet exist. It seems that Glenn's patch (with Eli's fix) was almost correct. After a bit of observation to the output of "msysconfig", I found a problem in this line: @(w32srcdir=`cd "$srcdir"; pwd -W | sed -e 's,^\([A-Za-z]\):,/\1,' | ${msys_to_w32}` ; \ ^^^^^^^ It seems that the shell was expanding "$s" to the empty string, so that the command finally executed was "cd rcdir; pwd -W | ..." I've fixed this by replacing "$srcdir" with "${srcdir}". So this is the final patch that has worked for me: diff --git a/Makefile.in b/Makefile.in index 461f0cb..39bdc5d 100644 --- a/Makefile.in +++ b/Makefile.in @@ -342,8 +342,16 @@ msys_sed_sh_escape=sed -e 's/[];$$*.^[]/\\\\&/g' # nt/epaths.nt as the template. # Use the value of ${locallisppath} supplied by `configure', # to support the --enable-locallisppath argument. +# +# When building with MinGW inside the MSYS tree, 'pwd' produces directories +# relative to the root of the MSYS tree, e.g. '/home/user/foo' instead of +# '/d/MSYS/home/user/foo'. If such a value of srcdir is written to +# src/epaths.h, that causes temacs to fail, because, being a MinGW +# program that knows nothing of MSYS root substitution, it cannot find +# the data directory. "pwd -W" produces Windows-style 'd:/foo/bar' +# absolute directory names, so we use it here to countermand that lossage. epaths-force-w32: FRC - @(w32srcdir=`echo "${abs_srcdir}" | ${msys_to_w32}` ; \ + @(w32srcdir=`cd "${srcdir}"; pwd -W | sed -e 's,^\([A-Za-z]\):,/\1,' | ${msys_to_w32}` ; \ prefixpattern=`echo '${prefix}' | ${msys_to_w32} | ${msys_sed_sh_escape}` ; \ locallisppath=`echo '${locallisppath}' | ${msys_lisppath_to_w32} | ${msys_prefix_subst}` ; \ sed < ${srcdir}/nt/epaths.nt > epaths.h.$$$$ \ diff --git a/configure.ac b/configure.ac index cb97564..a8fb34b 100644 --- a/configure.ac +++ b/configure.ac @@ -419,17 +419,6 @@ AC_ARG_ENABLE(gtk-deprecation-warnings, [Show Gtk+/Gdk deprecation warnings for Gtk+ >= 3.0])], [ac_enable_gtk_deprecation_warnings="${enableval}"],[]) -#### When building with MinGW inside the MSYS tree, 'pwd' produces -#### directories relative to the root of the MSYS tree, -#### e.g. '/home/user/foo' instead of '/d/MSYS/home/user/foo'. When -#### such a value of srcdir is written to the top-level Makefile, it -#### gets propagated to src/epaths.h, and that causes temacs to fail, -#### because, being a MinGW program that knows nothing of MSYS root -#### substitution, it cannot find the data directory. "pwd -W" -#### produces Windows-style 'd:/foo/bar' absolute directory names, so -#### we use it here to countermand that lossage. -test "$MSYSTEM" = "MINGW32" && abs_srcdir=`(cd "$abs_srcdir"; pwd -W | sed -e 's,^\([[A-Za-z]]\):,/\1,')` - ### Canonicalize the configuration name. AC_CANONICAL_HOST -- Dani Moncayo