Package: emacs;
Reported by: Ilya Zakharevich <nospam-abuse <at> ilyaz.org>
Date: Tue, 3 Mar 2015 16:48:01 UTC
Severity: minor
Found in version 25.0.50
Done: Noam Postavsky <npostavs <at> users.sourceforge.net>
Bug is archived. No further changes may be made.
Message #80 received at 19989 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Ilya Zakharevich <ilya <at> math.berkeley.edu> Cc: 19989 <at> debbugs.gnu.org Subject: Re: bug#19989: 25.0.50; Build instructions on Windows Date: Sat, 07 Mar 2015 11:04:41 +0200
> Date: Fri, 6 Mar 2015 17:35:02 -0800 > From: Ilya Zakharevich <ilya <at> math.berkeley.edu> > Cc: 19989 <at> debbugs.gnu.org > > What IS important is the fact that the PATH of > bash --login > won’t find the INSTALLED mingw. Let me repeat the same stuff again: > > • mingw-get installs mingw into > FOO/bin > (here FOO is the install path set in mingw-get) > • /etc/profile’s PATH contains > /mingw/bin > /bin > (among others) — but /mingw/bin is actually resolved (AFAICS) to > FOO/msys/1.0/mingw/bin > (and /bin to FOO/msys/1.0/bin). > > • Therefore, /mingw/bin is on PATH, but it is a non-existing > directory (even after mangling). > > • Now there are two cases of the PATH at start of `bash --login´: > ∘ If PATH contains some other gcc, then the other gcc will be > used by ./configure — with hard-to-explain failures; > ∘ If PATH does not contain gcc, then ./configure will quickly > fail, reporting not finding gcc. Repeating the same stuff over and over again won't get you anywhere useful. I understood what you wrote the first time. But, as usual, you didn't provide enough useful information that would allow a bystander understand what causes a "wrong" GCC to be found, and which "wrong" GCC was that. IOW, stop hand-waving and start divulging useful information about the broken setup you wound up with, and please do NOT withhold important details on the pretense that they are "not important" (as if you actually knew what is and what isn't). So, let's try one more time, and this time try to provide full answers with all the details: . In which directory do you have the MinGW gcc.exe? Please make a point of showing its full absolute directory file name, both as seen by Windows native programs and by MSYS Bash. Please do NOT substitute those stupid FOO placeholders, because they interfere with understanding the problem. In case you didn't know, to see the Windows-format file name of a directory that corresponds to some MSYS directory, you can do this in the MSYS Bash shell: $ cd /wherever/that/is && pwd -W . In which directory do you have the "wrong" gcc.exe? Please provide the same details about that as for the MinGW gcc.exe. . What is the full value of PATH, in MSYS Bash and in the Windows cmd.exe shell? . Where do you have the MinGW headers and *.a libraries? Please provide a full native Windows (not MSYS or Cygwin!) absolute file names of those directories. Note that I'm talking about *.a libraries, not *.dll. There should be at least 2 directories with them, one with libraries used by GCC, the other for linking against Windows w32 APIs and other external libraries, like image libraries and libxml. (In most installations, there are actually 4 directories, not 2; please list them all.) . If you installed any additional libraries that didn't come with MinGW, please provide the full absolute file names of the directories where you put their *.dll and *.a files, and their headers. If you installed those libraries in the same directories where you have the MinGW headers and libraries, it's enough to mention that fact; no need to provide the directories explicitly. . Which packages did you select in mingw-get when you downloaded MinGW and MSYS? Please provide a full list of those, and please make sure to point out which were selected by default, and which ones weren't and you yourself selected them. . Did mingw-get ask you any additional questions, apart of a single question in which directory to install the stuff? If it did, please provide details of any non-default selections you made, or any other gestures you did while downloading and installing. Armed with the above knowledge (assuming I'm going to get it), it is just possible that we will succeed in arriving at the understanding of what broke your installation, how to fix it, and how to avoid that in the first place. The latter part (if we ever get there) might help us amend the instructions in nt/INSTALL, if there's something to amend there. > (After discovering this — which stole a couple of hours of my time) I > needed to fix this. Because the way of MSYS mangling of paths is not > easily found, (and one cannot easily find MSYS’s /etc/profile), > instead of editing PATH, I just modified the filesystem, linking > FOO/msys/1.0/mingw > to > FOO/mingw > (experiments show that this must be a Windows’ style link — made with > sysinternal’s mklink, as reported). AFAIK, mklink is not from SysInternals, it's a stock Windows program that comes with every Windows box from Vista onward. And at least for creating symbolic links, it will trigger UAC elevation prompts (or silently fail). In any case, we are not going to ask users to install SysInternals as a means to build Emacs. And if what you intended is suggest that users be told to create a junction point to "fix" this, then no, we won't do that, either. Telling users to create junctions and symlinks is a bad idea, as it confuses many Windows programs, certainly those which are result of porting GNU and Unix stuff, which are usually built with symlink support disabled, and so cannot detect loops in the filesystem that links can create. If there is a problem, we will have to find a way of avoiding it without such kludges. Now, are you up to the task of actually helping us to make the instructions better? Or all you want is to demonstrate how stupid and inept we are? If the former, we might get somewhere; if the latter, there's nothing else to be said here.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.