bug#19989: 25.0.50; Build instructions on Windows

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

=======================================================

I needed the following changes to build Emacs (when following the
instructions in nt/INSTALL):
  • mingw-get:
	actually, mingw32-base is not installed by default;
        I needed to install it by manually marking it in mingw-get.
  • mingw shell sets path to (essentially) FOO/msys/1.0/mingw/bin (here FOO
        is the install path), but there is no directory
          FOO/msys/1.0/mingw
        what is is
          FOO/bin
    So I needed to make a symbolic link (Windows style required) by
    running
        mklink /j mingw FOO
    in FOO/msys/1.0

=======================================================



In GNU Emacs 25.0.50.20 (i686-pc-mingw32)
 of 2015-02-08 on BUCEFAL
Repository revision: d5e3922e08587e7eb9e5aec2e9f84cbda405f857
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/k/test'

Configured features:
SOUND NOTIFY ACL

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils time-date tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 ls-lisp disp-table w32-win w32-vars tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32notify w32 multi-tty emacs)

Memory information:
((conses 8 80324 9864)
 (symbols 32 17968 0)
 (miscs 32 85 128)
 (strings 16 12688 4007)
 (string-bytes 1 324435)
 (vectors 8 9470)
 (vector-slots 4 390690 6074)
 (floats 8 65 62)
 (intervals 28 243 45)
 (buffers 516 13))

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Tue, 3 Mar 2015 08:34:53 -0800
> From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
> 
> =======================================================
> 
> I needed the following changes to build Emacs (when following the
> instructions in nt/INSTALL):
>   • mingw-get:
> 	actually, mingw32-base is not installed by default;
>         I needed to install it by manually marking it in mingw-get.
>   • mingw shell sets path to (essentially) FOO/msys/1.0/mingw/bin (here FOO
>         is the install path), but there is no directory
>           FOO/msys/1.0/mingw
>         what is is
>           FOO/bin
>     So I needed to make a symbolic link (Windows style required) by
>     running
>         mklink /j mingw FOO
>     in FOO/msys/1.0

Thanks.

I suggest to post this to the MinGW mailing list
<mingw-users@lists.sourceforge.net> first, as what you describe sounds
like MinGW issues not directly related to building Emacs.  If they say
that this is "as designed", then we will see about adding something to
nt/INSTALL to work around this.

FWIW, the 2nd issue sounds to me like an installation mistake of some
kind (did you install MinGW inside the MSYS tree, by chance?).  But
I'm not an expert; all I know is that on my system, the MSYS Bash
window has PATH set to whatever my system-wide PATH is, with these
directories prepended:

  .:/usr/local/bin:/mingw/bin:/bin:

IOW, no msys/1.0/mingw/ anywhere in sight.

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Tue, 03 Mar 2015 19:00:09 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 19989@debbugs.gnu.org
> 
> >   • mingw shell sets path to (essentially) FOO/msys/1.0/mingw/bin (here FOO
> >         is the install path), but there is no directory
> >           FOO/msys/1.0/mingw
> >         what is is
> >           FOO/bin
> >     So I needed to make a symbolic link (Windows style required) by
> >     running
> >         mklink /j mingw FOO
> >     in FOO/msys/1.0
> [...]
> FWIW, the 2nd issue sounds to me like an installation mistake of some
> kind (did you install MinGW inside the MSYS tree, by chance?).  But
> I'm not an expert; all I know is that on my system, the MSYS Bash
> window has PATH set to whatever my system-wide PATH is, with these
> directories prepended:
> 
>   .:/usr/local/bin:/mingw/bin:/bin:
> 
> IOW, no msys/1.0/mingw/ anywhere in sight.

Btw, there's nothing magic in the PATH value: it is set in
/etc/profile (probably FOO/msys/etc/profile in your case), and you can
edit it to your heart's content.

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Tue, Mar 03, 2015 at 07:21:03PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 03 Mar 2015 19:00:09 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 19989@debbugs.gnu.org
> > 
> > >   • mingw shell sets path to (essentially) FOO/msys/1.0/mingw/bin (here FOO
> > >         is the install path), but there is no directory
> > >           FOO/msys/1.0/mingw
> > >         what is is
> > >           FOO/bin
> > >     So I needed to make a symbolic link (Windows style required) by
> > >     running
> > >         mklink /j mingw FOO
> > >     in FOO/msys/1.0

> > FWIW, the 2nd issue sounds to me like an installation mistake of some
> > kind (did you install MinGW inside the MSYS tree, by chance?).

How would I know?  I just ran mingw-get (as described), and set
install directory ( = FOO) once.

The result:
  FOO/bin		- contains gcc executables etc
  FOO/msys/1.0/		- contains msys
  FOO/msys/1.0/bin	- contains msys executables

> >  But
> > I'm not an expert; all I know is that on my system, the MSYS Bash
> > window has PATH set to whatever my system-wide PATH is, with these
> > directories prepended:
> > 
> >   .:/usr/local/bin:/mingw/bin:/bin:
> > 
> > IOW, no msys/1.0/mingw/ anywhere in sight.

???  Of course it IS in sight:

  /bin	       IS native   FOO/msys/1.0/bin
  /mingw/bin   IS native   FOO/msys/1.0/mingw/bin

> Btw, there's nothing magic in the PATH value: it is set in
> /etc/profile (probably FOO/msys/etc/profile in your case), and you can
> edit it to your heart's content.

Only if one KNOWS what all these slashes-etc MEAN.  As you see, even
*you* got lost what denotes which native directory.  If what the users
know is what is in nt/INSTALL, they have no way to deduce this info.   

=======================================================

BTW: you reminded me: there is another bug in Emacs build — this one
purely in Emacs.  My default PATH accesses a complete cygwin
installation, and:

  •  Emacs won’t build unless I unset PATH before running the msys shell.

I expect that the detection of presence of dependencies is not
“specific enough”:

  • it can see “something” present on PATH, and
  • it does not check that “this” won’t actually build with mingw
    being first on PATH. 

Ilya

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Tue, 3 Mar 2015 12:30:37 -0800
> From: Ilya Zakharevich <ilya@math.berkeley.edu>
> Cc: 19989@debbugs.gnu.org
> 
> On Tue, Mar 03, 2015 at 07:21:03PM +0200, Eli Zaretskii wrote:
> > > Date: Tue, 03 Mar 2015 19:00:09 +0200
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > Cc: 19989@debbugs.gnu.org
> > > 
> > > >   • mingw shell sets path to (essentially) FOO/msys/1.0/mingw/bin (here FOO
> > > >         is the install path), but there is no directory
> > > >           FOO/msys/1.0/mingw
> > > >         what is is
> > > >           FOO/bin
> > > >     So I needed to make a symbolic link (Windows style required) by
> > > >     running
> > > >         mklink /j mingw FOO
> > > >     in FOO/msys/1.0
> 
> > > FWIW, the 2nd issue sounds to me like an installation mistake of some
> > > kind (did you install MinGW inside the MSYS tree, by chance?).
> 
> How would I know?

You could look at the directory hierarchy that got created.

> I just ran mingw-get (as described), and set
> install directory ( = FOO) once.

Did you select the same install directory for MinGW and for MSYS?

> The result:
>   FOO/bin		- contains gcc executables etc
>   FOO/msys/1.0/		- contains msys
>   FOO/msys/1.0/bin	- contains msys executables
> 
> > >  But
> > > I'm not an expert; all I know is that on my system, the MSYS Bash
> > > window has PATH set to whatever my system-wide PATH is, with these
> > > directories prepended:
> > > 
> > >   .:/usr/local/bin:/mingw/bin:/bin:
> > > 
> > > IOW, no msys/1.0/mingw/ anywhere in sight.
> 
> ???  Of course it IS in sight:
> 
>   /bin	       IS native   FOO/msys/1.0/bin
>   /mingw/bin   IS native   FOO/msys/1.0/mingw/bin

But then there's no problem, because missing directories on PATH do no
harm.  The binaries are in /bin, and it is on PATH, so there should be
no problem; there isn't one in my installation.  (Of course, I didn't
use mingw-get, but instead installed stuff by manually unpacking the
tarballs in the first place.)

> > Btw, there's nothing magic in the PATH value: it is set in
> > /etc/profile (probably FOO/msys/etc/profile in your case), and you can
> > edit it to your heart's content.
> 
> Only if one KNOWS what all these slashes-etc MEAN.

/etc/profile is a standard place in many Posix shells.

> As you see, even
> *you* got lost what denotes which native directory.  If what the users
> know is what is in nt/INSTALL, they have no way to deduce this info.   

I wasn't talking about some abstract user, I was trying to help you to
get your installation in good shape.

> BTW: you reminded me: there is another bug in Emacs build — this one
> purely in Emacs.  My default PATH accesses a complete cygwin
> installation

How does Cygwin enter this equation?  Do you have both Cygwin and
MinGW/MSYS installed?

>   •  Emacs won’t build unless I unset PATH before running the msys shell.
> 
> I expect that the detection of presence of dependencies is not
> “specific enough”:
> 
>   • it can see “something” present on PATH, and
>   • it does not check that “this” won’t actually build with mingw
>     being first on PATH. 

If you mix incompatible stuff in the same shell session, you get what
you deserve.  My advice is to have MSYS in separate tree from MinGW,
and only let MSYS shell see MinGW executables _after_ its own.  MinGW,
OTOH, should not have the MSYS's /bin directory on its PATH.  As for
Cygwin, it should be in yet another segregated tree, and never on the
same PATH as either MSYS or MinGW.  It is next to impossible to have
the Posix configure scripts distinguish between foo.exe or foo.h that
are for Cygwin and their namesakes for MinGW.

Like I said: you need to get your MinGW/MSYS installation in good
shape, and then things will work seamlessly.  This isn't an Emacs
issue, per se.

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Wed, Mar 04, 2015 at 05:42:59AM +0200, Eli Zaretskii wrote:
> > > > >   • mingw shell sets path to (essentially) FOO/msys/1.0/mingw/bin (here FOO
> > > > >         is the install path), but there is no directory
> > > > >           FOO/msys/1.0/mingw
> > > > >         what is is
> > > > >           FOO/bin
> > > > >     So I needed to make a symbolic link (Windows style required) by
> > > > >     running
> > > > >         mklink /j mingw FOO
> > > > >     in FOO/msys/1.0
> > 
> > > > FWIW, the 2nd issue sounds to me like an installation mistake of some
> > > > kind (did you install MinGW inside the MSYS tree, by chance?).
> > 
> > How would I know?
> 
> You could look at the directory hierarchy that got created.

*This* I did — and I reported the result in my initial message (quoted
below).  This does not answer your question.

> > I just ran mingw-get (as described), and set
> > install directory ( = FOO) once.
> 
> Did you select the same install directory for MinGW and for MSYS?

AFAIR, there was no “install directory ‘for”’.  Only “install directory”.

> > The result:
> >   FOO/bin		- contains gcc executables etc
> >   FOO/msys/1.0/		- contains msys
> >   FOO/msys/1.0/bin	- contains msys executables

> > > >  But
> > > > I'm not an expert; all I know is that on my system, the MSYS Bash
> > > > window has PATH set to whatever my system-wide PATH is, with these
> > > > directories prepended:
> > > > 
> > > >   .:/usr/local/bin:/mingw/bin:/bin:
> > > > 
> > > > IOW, no msys/1.0/mingw/ anywhere in sight.
> > 
> > ???  Of course it IS in sight:
> > 
> >   /bin	       IS native   FOO/msys/1.0/bin
> >   /mingw/bin   IS native   FOO/msys/1.0/mingw/bin
> 
> But then there's no problem, because missing directories on PATH do no
> harm.

Of course they do.  configure did not work (since the gcc found on
path was not MINGW one).

> The binaries are in /bin, and it is on PATH, so there should be
> no problem; there isn't one in my installation.

Are you joking?!  What do you think is a reason for filing bug
reports?  I followed instructions, AND GOT PROBLEMS!

> > > Btw, there's nothing magic in the PATH value: it is set in
> > > /etc/profile (probably FOO/msys/etc/profile in your case), and you can
> > > edit it to your heart's content.
> > 
> > Only if one KNOWS what all these slashes-etc MEAN.
> 
> /etc/profile is a standard place in many Posix shells.

How would it help?  How would the user find it on their disk?

> > As you see, even
> > *you* got lost what denotes which native directory.  If what the users
> > know is what is in nt/INSTALL, they have no way to deduce this info.   
> 
> I wasn't talking about some abstract user, I was trying to help you to
> get your installation in good shape.

Thanks!  But did I ask for that?  This is a bug report, not a cry for
help.  Emacs builds fine now — but I needed 3 corrections to what is
written in nt/INSTALL to achieve this.

> > BTW: you reminded me: there is another bug in Emacs build — this one
> > purely in Emacs.  My default PATH accesses a complete cygwin
> > installation

> How does Cygwin enter this equation?  Do you have both Cygwin and
> MinGW/MSYS installed?

I have tens of environment installed.  cygwin is on PATH.

> >   •  Emacs won’t build unless I unset PATH before running the msys shell.
> > 
> > I expect that the detection of presence of dependencies is not
> > “specific enough”:
> > 
> >   • it can see “something” present on PATH, and
> >   • it does not check that “this” won’t actually build with mingw
> >     being first on PATH. 
> 
> If you mix incompatible stuff in the same shell session, you get what
> you deserve.

Sigh…  Again — all I did was following instructions in nt/INSTALL.

>  My advice is to have MSYS in separate tree from MinGW,

Is this advice in nt/INSTALL?  And how to do it from mingw-get?

> and only let MSYS shell see MinGW executables _after_ its own.  MinGW,
> OTOH, should not have the MSYS's /bin directory on its PATH.

Same questions.

> As for Cygwin, it should be in yet another segregated tree,

It is.

> and never on the same PATH as either MSYS or MinGW.

It was not in *MY* $PATH.  It was in the $PATH created by /etc/profile
which was created following instructions in nt/INSTALL.

> It is next to impossible to have
> the Posix configure scripts distinguish between foo.exe or foo.h that
> are for Cygwin and their namesakes for MinGW.

For foo.exe — one does not care.  For foo.h — one compiles and runs a
simple program.

> Like I said: you need to get your MinGW/MSYS installation in good
> shape, and then things will work seamlessly.  This isn't an Emacs
> issue, per se.

Again: this is an issue with nt/INSTALL.  Who distributes it, the god
almoighty?

Thanks again,
Ilya

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Thu, 5 Mar 2015 13:18:21 -0800
> From: Ilya Zakharevich <ilya@math.berkeley.edu>
> Cc: 19989@debbugs.gnu.org
> 
> On Wed, Mar 04, 2015 at 05:42:59AM +0200, Eli Zaretskii wrote:
> > > > > >   • mingw shell sets path to (essentially) FOO/msys/1.0/mingw/bin (here FOO
> > > > > >         is the install path), but there is no directory
> > > > > >           FOO/msys/1.0/mingw
> > > > > >         what is is
> > > > > >           FOO/bin
> > > > > >     So I needed to make a symbolic link (Windows style required) by
> > > > > >     running
> > > > > >         mklink /j mingw FOO
> > > > > >     in FOO/msys/1.0
> > > 
> > > > > FWIW, the 2nd issue sounds to me like an installation mistake of some
> > > > > kind (did you install MinGW inside the MSYS tree, by chance?).
> > > 
> > > How would I know?
> > 
> > You could look at the directory hierarchy that got created.
> 
> *This* I did — and I reported the result in my initial message (quoted
> below).  This does not answer your question.

It doesn't answer the question, indeed, because you didn't say where
MinGW programs are, only what PATH you see in the MSYS shell window.
And the PATH you reported was not exactly what you saw, AFAIU, at
least that's what follows from the "(essentially)
FOO/msys/1.0/mingw/bin" part.

> > > I just ran mingw-get (as described), and set
> > > install directory ( = FOO) once.
> > 
> > Did you select the same install directory for MinGW and for MSYS?
> 
> AFAIR, there was no “install directory ‘for”’.  Only “install directory”.

I'm asking if they share the same directory tree.  Can you show the
entire tree, e.g. by running 'find -type d'?

> > > The result:
> > >   FOO/bin		- contains gcc executables etc
> > >   FOO/msys/1.0/		- contains msys
> > >   FOO/msys/1.0/bin	- contains msys executables
> 
> > > > >  But
> > > > > I'm not an expert; all I know is that on my system, the MSYS Bash
> > > > > window has PATH set to whatever my system-wide PATH is, with these
> > > > > directories prepended:
> > > > > 
> > > > >   .:/usr/local/bin:/mingw/bin:/bin:
> > > > > 
> > > > > IOW, no msys/1.0/mingw/ anywhere in sight.
> > > 
> > > ???  Of course it IS in sight:
> > > 
> > >   /bin	       IS native   FOO/msys/1.0/bin
> > >   /mingw/bin   IS native   FOO/msys/1.0/mingw/bin
> > 
> > But then there's no problem, because missing directories on PATH do no
> > harm.
> 
> Of course they do.  configure did not work (since the gcc found on
> path was not MINGW one).

So that's the problem: you installed the MSYS GCC (and probably the
whole MSYS development environment), something one shouldn't do for
building MinGW programs.  The MSYS GCC and development environment is
for developing MSYS programs, like the MSYS Bash etc. -- you don't
want and don't need that.

> > The binaries are in /bin, and it is on PATH, so there should be
> > no problem; there isn't one in my installation.
> 
> Are you joking?!  What do you think is a reason for filing bug
> reports?  I followed instructions, AND GOT PROBLEMS!

Well, now I at least understand the reason for your problems: an extra
development environment that gets in your way.  I didn't understand
that before, sorry for being too stupid.

> > /etc/profile is a standard place in many Posix shells.
> 
> How would it help?  How would the user find it on their disk?
> 
> > > As you see, even
> > > *you* got lost what denotes which native directory.  If what the users
> > > know is what is in nt/INSTALL, they have no way to deduce this info.   
> > 
> > I wasn't talking about some abstract user, I was trying to help you to
> > get your installation in good shape.
> 
> Thanks!  But did I ask for that?  This is a bug report, not a cry for
> help.

I don't think it's a bug report about Emacs.  Your development
environment was botched (and maybe still is, if you didn't uninstall
the MSYS GCC).

> > > BTW: you reminded me: there is another bug in Emacs build — this one
> > > purely in Emacs.  My default PATH accesses a complete cygwin
> > > installation
> 
> > How does Cygwin enter this equation?  Do you have both Cygwin and
> > MinGW/MSYS installed?
> 
> I have tens of environment installed.  cygwin is on PATH.

I suggest to remove it.  You might have additional runtime problems,
e.g. if there are DLLs there that Emacs looks for, whose names are
identical to their MinGW namesakes.  It's a problem waiting to happen.
You can avoid it by being extra-vigilant, and carefully set up the
order of directories, but it's easier to side-step the problem to
begin with.

> > If you mix incompatible stuff in the same shell session, you get what
> > you deserve.
> 
> Sigh…  Again — all I did was following instructions in nt/INSTALL.

If those instructions somehow cause you to download the MSYS
development environment, please tell how to amend them as to avoid
that.  These instructions exist for quite some time, and no one has
bumped into this particular problem yet.  (I myself don't use
mingw-get, so the part in the instructions for using it was provided
by someone else who did.)

> >  My advice is to have MSYS in separate tree from MinGW,
> 
> Is this advice in nt/INSTALL?

Yes:

  MSYS packages should be installed in a separate tree from MinGW.
  For example, use D:\MSYS or D:\usr\MSYS as the top-level directory
  from which you unpack all of the MSYS packages.

> And how to do it from mingw-get?

If someone knows how to do that with mingw-get, please tell.

> > and only let MSYS shell see MinGW executables _after_ its own.  MinGW,
> > OTOH, should not have the MSYS's /bin directory on its PATH.
> 
> Same questions.

Same answers:

  Do NOT add the MSYS bin directory to your Windows Path!  Only the
  MinGW bin directory should be on Path.  When you install MSYS, it
  creates a shortcut on your desktop that invokes the MSYS Bash shell
  in a Command Prompt window; that shell is already set up so that the
  MSYS bin directory is on PATH ahead of any other directory.  Thus,
  Bash will find MSYS executables first, which is exactly what you
  need.

> > As for Cygwin, it should be in yet another segregated tree,
> 
> It is.
> 
> > and never on the same PATH as either MSYS or MinGW.
> 
> It was not in *MY* $PATH.  It was in the $PATH created by /etc/profile
> which was created following instructions in nt/INSTALL.

/etc/profile just takes your PATH and prepends a few directories to
it, that's all.

> > It is next to impossible to have
> > the Posix configure scripts distinguish between foo.exe or foo.h that
> > are for Cygwin and their namesakes for MinGW.
> 
> For foo.exe — one does not care.  For foo.h — one compiles and runs a
> simple program.

See above: you forget the DLLs, for which Windows has quite a
convoluted search algorithm.

> > Like I said: you need to get your MinGW/MSYS installation in good
> > shape, and then things will work seamlessly.  This isn't an Emacs
> > issue, per se.
> 
> Again: this is an issue with nt/INSTALL.

We need to identify the issues first.

One issue is now clear: the MSYS development environment should not be
installed.  The manual instructions take care of that: they provide a
list of packages to install; for the mingw-get instructions I'd
appreciate if someone who uses it says how to avoid it.

The other part is Cygwin; if you want to keep it on PATH, and you know
what you are doing, fine.  It's not the job of nt/INSTALL to tell
users how to configure their systems to avoid future trouble.

Are there any other issues?  If so, can you suggest specific changes
to nt/INSTALL.

bug#19989: 25.0.50; Build instructions on Windows

[martin rudalics]

 > If those instructions somehow cause you to download the MSYS
 > development environment, please tell how to amend them as to avoid
 > that.  These instructions exist for quite some time, and no one has
 > bumped into this particular problem yet.  (I myself don't use
 > mingw-get, so the part in the instructions for using it was provided
 > by someone else who did.)

Setting up mingw without mingw-get from scratch (resolving all the
necessary dependencies) looks like it could take at least a week here.
Maybe I'm wrong but it appears that every DL and installation step has
to be prepared carefully wrt overwriting (or not) previously installed
libraries.

Using mingw-get (which I did) is complicated as well if you want to
avoid falling into one of the traps mentioned in this thread.

martin

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Fri, Mar 06, 2015 at 10:21:49AM +0100, martin rudalics wrote:
> Setting up mingw without mingw-get from scratch (resolving all the
> necessary dependencies) looks like it could take at least a week here.
> Maybe I'm wrong but it appears that every DL and installation step has
> to be prepared carefully wrt overwriting (or not) previously installed
> libraries.
> 
> Using mingw-get (which I did) is complicated as well if you want to
> avoid falling into one of the traps mentioned in this thread.

I think building Emacs stole about 10 hours of my active time.
However, I must mention that the MAIN problem was:

  A) apparently, the download and build instructions changes not so
     long ago, so what google finds are obsolete irrelevant
     instructions.

  B) Since I got many different versions of Emacs build tree
     downloaded, I might have mixed up all the BAR/nt/INSTALL.  Do not
     know how did it happen EXACTLY, but for several rounds I was
     thinking I MUST run
        nt/configure.bat

The warning which nt/configure.bat gives is not specific enough (at
least when shown on background of all the [wrong] info found by googling):

echo ****************************************************************
echo *** THIS METHOD OF BUILDING EMACS IS NO LONGER SUPPORTED.     **
echo *** INSTEAD, FOLLOW THE INSTRUCTIONS FROM INSTALL.            **
echo ****************************************************************

--------------------------------------------

I cannot be sure, but I suspect that if it would show an extra line:

     **** The current way is to install MSYS and MINGW,          ****  
     ****    and run the top-level configure script.             ****

this might have saved me about half of these 10 hours.  (But it might
have been my very personal way to confuse myself, and this extra
message won’t be so useful for other people.) 

Ilya

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Fri, 6 Mar 2015 01:59:52 -0800
> From: Ilya Zakharevich <ilya@math.berkeley.edu>
> Cc: Eli Zaretskii <eliz@gnu.org>, 19989@debbugs.gnu.org
> 
>   A) apparently, the download and build instructions changes not so
>      long ago, so what google finds are obsolete irrelevant
>      instructions.

The build instructions changed in May 2013, almost 2 years ago.

> The warning which nt/configure.bat gives is not specific enough (at
> least when shown on background of all the [wrong] info found by googling):

If no one complains about something major for the MinGW/MSYS build
when Emacs 24.5 is released, nt/configure.bat will be deleted from the
repository, so it won't be able to confuse anyone anymore.

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Fri, Mar 06, 2015 at 01:16:36PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 6 Mar 2015 01:59:52 -0800
> > From: Ilya Zakharevich <ilya@math.berkeley.edu>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 19989@debbugs.gnu.org
> > 
> >   A) apparently, the download and build instructions changes not so
> >      long ago, so what google finds are obsolete irrelevant
> >      instructions.
> 
> The build instructions changed in May 2013, almost 2 years ago.

Irrelevant.  Google brings (many variants) of wrong instructions about
  • what to download
  • how to build it
 — and no correct instructions (at least close to the top of the list;
my google shows 80 hits, and it did not help much).
 
If you download an obsolete version, you get obsolete instructions
(coming with this version).  So it is hard to detect that what you get
is bogus.

> > The warning which nt/configure.bat gives is not specific enough (at
> > least when shown on background of all the [wrong] info found by googling):
> 
> If no one complains about something major for the MinGW/MSYS build
> when Emacs 24.5 is released, nt/configure.bat will be deleted from the
> repository, so it won't be able to confuse anyone anymore.

In view of the results of googling, I would prefer if this file were
kept, but would produce a message like

     Build via nt/configure.bat is replaced by a build via:
       installing MSYS, MINGW, and running the top-level configure.
     See nt/INSTALL for details.

Ilya

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Fri, 6 Mar 2015 17:44:04 -0800
> From: Ilya Zakharevich <ilya@math.berkeley.edu>
> Cc: rudalics@gmx.at, 19989@debbugs.gnu.org
> 
> On Fri, Mar 06, 2015 at 01:16:36PM +0200, Eli Zaretskii wrote:
> > > Date: Fri, 6 Mar 2015 01:59:52 -0800
> > > From: Ilya Zakharevich <ilya@math.berkeley.edu>
> > > Cc: Eli Zaretskii <eliz@gnu.org>, 19989@debbugs.gnu.org
> > > 
> > >   A) apparently, the download and build instructions changes not so
> > >      long ago, so what google finds are obsolete irrelevant
> > >      instructions.
> > 
> > The build instructions changed in May 2013, almost 2 years ago.
> 
> Irrelevant.

Relevant.  You should look at the date of the instructions you get
from Google before you consider them valid.

> Google brings (many variants) of wrong instructions about
>   • what to download
>   • how to build it
>  — and no correct instructions (at least close to the top of the list;
> my google shows 80 hits, and it did not help much).

Which might mean that everybody else succeeded in building Emacs just
by following nt/INSTALL.

> If you download an obsolete version, you get obsolete instructions
> (coming with this version).  So it is hard to detect that what you get
> is bogus.

The first place to look is in the package, not in Google hits.  Follow
that rule, and you will be generally fine, not only with Emacs.

> > > The warning which nt/configure.bat gives is not specific enough (at
> > > least when shown on background of all the [wrong] info found by googling):
> > 
> > If no one complains about something major for the MinGW/MSYS build
> > when Emacs 24.5 is released, nt/configure.bat will be deleted from the
> > repository, so it won't be able to confuse anyone anymore.
> 
> In view of the results of googling, I would prefer if this file were
> kept, but would produce a message like
> 
>      Build via nt/configure.bat is replaced by a build via:
>        installing MSYS, MINGW, and running the top-level configure.
>      See nt/INSTALL for details.

Leaving the file for that purpose makes no sense.  If someone is
looking for it because it was mentioned in some Google hit, they will
know the hit was outdated.

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Sat, Mar 07, 2015 at 11:11:45AM +0200, Eli Zaretskii wrote:
> > > >   A) apparently, the download and build instructions changes not so
> > > >      long ago, so what google finds are obsolete irrelevant
> > > >      instructions.
> > > 
> > > The build instructions changed in May 2013, almost 2 years ago.
> > 
> > Irrelevant.
> 
> Relevant.  You should look at the date of the instructions you get
> from Google before you consider them valid.

Think about what you suggest: suppose the instructions are of May
2014.  How the user would know whether it is VALID or NOT?

> > Google brings (many variants) of wrong instructions about
> >   • what to download
> >   • how to build it
> >  — and no correct instructions (at least close to the top of the list;
> > my google shows 80 hits, and it did not help much).
> 
> Which might mean that everybody else succeeded in building Emacs just
> by following nt/INSTALL.

I agree that this IS a quality indicator!  Unfortunately, this does
not help the googling giving poisoned pills.

> > If you download an obsolete version, you get obsolete instructions
> > (coming with this version).  So it is hard to detect that what you get
> > is bogus.
> 
> The first place to look is in the package, not in Google hits.  Follow
> that rule, and you will be generally fine, not only with Emacs.

Are you sure?  This is chicken and eggs problem.  If I did not find
the package (with instructions), how do I find where to find the
package?

> 
> > > > The warning which nt/configure.bat gives is not specific enough (at
> > > > least when shown on background of all the [wrong] info found by googling):
> > > 
> > > If no one complains about something major for the MinGW/MSYS build
> > > when Emacs 24.5 is released, nt/configure.bat will be deleted from the
> > > repository, so it won't be able to confuse anyone anymore.
> > 
> > In view of the results of googling, I would prefer if this file were
> > kept, but would produce a message like
> > 
> >      Build via nt/configure.bat is replaced by a build via:
> >        installing MSYS, MINGW, and running the top-level configure.
> >      See nt/INSTALL for details.
> 
> Leaving the file for that purpose makes no sense.  If someone is
> looking for it because it was mentioned in some Google hit, they will
> know the hit was outdated.

This conclusion (“hit was outdated”) involves logical deduction in a
fuzzy world.  One can expect that THIS result of deduction is
possible — but ANY OTHER result is possible too.

Ilya

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Fri, 06 Mar 2015 13:16:36 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 19989@debbugs.gnu.org
> 
> > Date: Fri, 6 Mar 2015 01:59:52 -0800
> > From: Ilya Zakharevich <ilya@math.berkeley.edu>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 19989@debbugs.gnu.org
> > 
> >   A) apparently, the download and build instructions changes not so
> >      long ago, so what google finds are obsolete irrelevant
> >      instructions.
> 
> The build instructions changed in May 2013, almost 2 years ago.
> 
> > The warning which nt/configure.bat gives is not specific enough (at
> > least when shown on background of all the [wrong] info found by googling):
> 
> If no one complains about something major for the MinGW/MSYS build
> when Emacs 24.5 is released, nt/configure.bat will be deleted from the
> repository, so it won't be able to confuse anyone anymore.

Done (except that instead of deleting configure.bat, I took your
advice and left it with just the reference to the new build
procedure).  All the other support files, mainly makefile.w32-in in
the various directories, were deleted from the master branch.

bug#19989: 25.0.50; Build instructions on Windows

[Dani Moncayo]

>> If no one complains about something major for the MinGW/MSYS build
>> when Emacs 24.5 is released, nt/configure.bat will be deleted from the
>> repository, so it won't be able to confuse anyone anymore.
>
> Done (except that instead of deleting configure.bat, I took your
> advice and left it with just the reference to the new build
> procedure).  All the other support files, mainly makefile.w32-in in
> the various directories, were deleted from the master branch.

Eli, I've noticed that the file 'nt/zipdist.bat' was not removed by
the above change.  I think it should, no?

-- 
Dani Moncayo

bug#19989: 25.0.50; Build instructions on Windows

[Dani Moncayo]

On Sat, Aug 15, 2015 at 1:22 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
>>> If no one complains about something major for the MinGW/MSYS build
>>> when Emacs 24.5 is released, nt/configure.bat will be deleted from the
>>> repository, so it won't be able to confuse anyone anymore.
>>
>> Done (except that instead of deleting configure.bat, I took your
>> advice and left it with just the reference to the new build
>> procedure).  All the other support files, mainly makefile.w32-in in
>> the various directories, were deleted from the master branch.
>
> Eli, I've noticed that the file 'nt/zipdist.bat' was not removed by
> the above change.  I think it should, no?

BTW, there are other ".bat" files besides 'nt/zipdist.bat'.  I wonder
whether the are still needed:

---------------------------
$ find . -name '*.bat'
./admin/nt/dump.bat
./config.bat
./msdos/depfiles.bat
./nt/configure.bat
./nt/ftime-nostartup.bat
./nt/ftime.bat
./nt/zipdist.bat
---------------------------

--
Dani Moncayo

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Sat, 15 Aug 2015 13:38:48 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 19989@debbugs.gnu.org
> 
> BTW, there are other ".bat" files besides 'nt/zipdist.bat'.  I wonder
> whether the are still needed:
> 
> ---------------------------
> $ find . -name '*.bat'
> ./admin/nt/dump.bat
> ./config.bat
> ./msdos/depfiles.bat
> ./nt/configure.bat
> ./nt/ftime-nostartup.bat
> ./nt/ftime.bat
> ./nt/zipdist.bat
> ---------------------------

I checked them all, and concluded they were unrelated (those in msdos/
certainly are).

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Sat, 15 Aug 2015 13:22:18 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 19989@debbugs.gnu.org
> 
> >> If no one complains about something major for the MinGW/MSYS build
> >> when Emacs 24.5 is released, nt/configure.bat will be deleted from the
> >> repository, so it won't be able to confuse anyone anymore.
> >
> > Done (except that instead of deleting configure.bat, I took your
> > advice and left it with just the reference to the new build
> > procedure).  All the other support files, mainly makefile.w32-in in
> > the various directories, were deleted from the master branch.
> 
> Eli, I've noticed that the file 'nt/zipdist.bat' was not removed by
> the above change.  I think it should, no?

I wouldn't know.  Is it not useful outside that old build procedure?

bug#19989: 25.0.50; Build instructions on Windows

[Dani Moncayo]

>> Eli, I've noticed that the file 'nt/zipdist.bat' was not removed by
>> the above change.  I think it should, no?
>
> I wouldn't know.  Is it not useful outside that old build procedure?

It was used by the (now obsolete) "dist" target.  I don't think it's
worth keeping it anymore in the repo.

-- 
Dani Moncayo

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Sat, 15 Aug 2015 14:24:16 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 19989@debbugs.gnu.org
> 
> >> Eli, I've noticed that the file 'nt/zipdist.bat' was not removed by
> >> the above change.  I think it should, no?
> >
> > I wouldn't know.  Is it not useful outside that old build procedure?
> 
> It was used by the (now obsolete) "dist" target.  I don't think it's
> worth keeping it anymore in the repo.

OK, then feel free to delete.

bug#19989: 25.0.50; Build instructions on Windows

[Dani Moncayo]

>> >> Eli, I've noticed that the file 'nt/zipdist.bat' was not removed by
>> >> the above change.  I think it should, no?
>> >
>> > I wouldn't know.  Is it not useful outside that old build procedure?
>>
>> It was used by the (now obsolete) "dist" target.  I don't think it's
>> worth keeping it anymore in the repo.
>
> OK, then feel free to delete.

Done.  Thanks.

-- 
Dani Moncayo

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Fri, 06 Mar 2015 10:21:49 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19989@debbugs.gnu.org
> 
> Maybe I'm wrong but it appears that every DL and installation step has
> to be prepared carefully wrt overwriting (or not) previously installed
> libraries.

The only rule I follow (religiously, btw) is not to overwrite a DLL
with an older one, judging by its time stamp.  I didn't find any other
issues.

> Using mingw-get (which I did) is complicated as well if you want to
> avoid falling into one of the traps mentioned in this thread.

The question is: can we amend the instructions to make them less
error-prone?  The manual instructions are very detailed, and I can
vouch for their correctness because that's what I used.  The mingw-get
instructions are from someone else, so those who use it are kindly
requested to help with making them better, as much as possible.

bug#19989: 25.0.50; Build instructions on Windows

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Using mingw-get (which I did) is complicated as well if you want to
>> avoid falling into one of the traps mentioned in this thread.
>
> The question is: can we amend the instructions to make them less
> error-prone?

Another option is to recommend MSYS2 for those interested on building
Emacs on Windows. It is a straightforward process.

I'll add the instructions one of this days.

bug#19989: 25.0.50; Build instructions on Windows

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Using mingw-get (which I did) is complicated as well if you want to
>> avoid falling into one of the traps mentioned in this thread.
>
> The question is: can we amend the instructions to make them less
> error-prone?

Another option is to recommend MSYS2 for those interested on building
Emacs on Windows. It is a straightforward process.

I'll add the instructions one of this days.

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: martin rudalics <rudalics@gmx.at>,  19989@debbugs.gnu.org,  ilya@math.berkeley.edu
> Date: Fri, 06 Mar 2015 15:14:29 +0100
> 
> Another option is to recommend MSYS2 for those interested on building
> Emacs on Windows. It is a straightforward process.
> 
> I'll add the instructions one of this days.

Thanks!

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Fri, Mar 06, 2015 at 03:14:29PM +0100, Óscar Fuentes wrote:
> Another option is to recommend MSYS2 for those interested on building
> Emacs on Windows. It is a straightforward process.

Is there any technical reason for not going the way of
  CC=i686-pc-mingw32-gcc
  LINK=i686-pc-mingw32-gcc
  ./configure
  make
in cygwin’s bash?

Ilya

bug#19989: 25.0.50; Build instructions on Windows

[Óscar Fuentes]

Ilya Zakharevich <ilya@math.berkeley.edu> writes:

> On Fri, Mar 06, 2015 at 03:14:29PM +0100, Óscar Fuentes wrote:
>> Another option is to recommend MSYS2 for those interested on building
>> Emacs on Windows. It is a straightforward process.
>
> Is there any technical reason for not going the way of
>   CC=i686-pc-mingw32-gcc
>   LINK=i686-pc-mingw32-gcc
>   ./configure
>   make
> in cygwin’s bash?

I can't comment on that because I stopped using cygwin long time ago,
but the main advantage of MSYS2 is that it just requires to run one
installer and then it resolves the dependencies problem (which is the
real hurdle) since all those dependencies are available from its package
repository and can be installed with one command:

$ pacman -S <list of required packages>

I intend to provide a script that runs that command so the user does not
need to figure out the list.

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Fri, 6 Mar 2015 17:47:21 -0800
> From: Ilya Zakharevich <ilya@math.berkeley.edu>
> Cc: Eli Zaretskii <eliz@gnu.org>, martin rudalics <rudalics@gmx.at>,
>  19989@debbugs.gnu.org
> 
> On Fri, Mar 06, 2015 at 03:14:29PM +0100, Óscar Fuentes wrote:
> > Another option is to recommend MSYS2 for those interested on building
> > Emacs on Windows. It is a straightforward process.
> 
> Is there any technical reason for not going the way of
>   CC=i686-pc-mingw32-gcc
>   LINK=i686-pc-mingw32-gcc
>   ./configure
>   make
> in cygwin’s bash?

I don't think anyone tried that.

One problem you might bump into is that building Emacs requires to
actually run Emacs you've built, and also lib-src/make-docfile, which
are not Cygwin programs.  If the Cygwin shell invokes them with
Cygwin-style absolute file names, these programs might fail, claiming
that files don't exist.  That's exactly the problem that MSYS attempts
to solve; it is otherwise just a fork of Cygwin.

bug#19989: 25.0.50; Build instructions on Windows

[martin rudalics]

 > The only rule I follow (religiously, btw) is not to overwrite a DLL
 > with an older one, judging by its time stamp.  I didn't find any other
 > issues.

When I am busy resolving dependencies it's easy to sidestep this rule at
least once.  You have a well maintained code base and much superior
knowledge.  Starting from scratch is not comparable to that.

martin

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Fri, 06 Mar 2015 19:53:24 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: ilya@math.berkeley.edu, 19989@debbugs.gnu.org
> 
>  > The only rule I follow (religiously, btw) is not to overwrite a DLL
>  > with an older one, judging by its time stamp.  I didn't find any other
>  > issues.
> 
> When I am busy resolving dependencies it's easy to sidestep this rule at
> least once.

It depends on which tools you use to unpack.  If the tools allow you
to say "do not override with older files", the probability of errors
is greatly reduced.

> You have a well maintained code base and much superior knowledge.
> Starting from scratch is not comparable to that.

I, too, started from scratch at some point ;-)

bug#19989: 25.0.50; Build instructions on Windows

[martin rudalics]

 > It depends on which tools you use to unpack.  If the tools allow you
 > to say "do not override with older files", the probability of errors
 > is greatly reduced.

The tools say that.  The problematic component is the person using them.

 >> You have a well maintained code base and much superior knowledge.
 >> Starting from scratch is not comparable to that.
 >
 > I, too, started from scratch at some point ;-)

So all I can hope is that one day all your machines, backups and notes
crash simultaneously, you forget everything you've done before in this
area, have to start from scratch again and will publish here what you've
done to produce a working environment :-(

martin

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Sat, 07 Mar 2015 10:40:56 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: ilya@math.berkeley.edu, 19989@debbugs.gnu.org
> 
>  > It depends on which tools you use to unpack.  If the tools allow you
>  > to say "do not override with older files", the probability of errors
>  > is greatly reduced.
> 
> The tools say that.  The problematic component is the person using them.

Can't do much to help that ;-)

>  >> You have a well maintained code base and much superior knowledge.
>  >> Starting from scratch is not comparable to that.
>  >
>  > I, too, started from scratch at some point ;-)
> 
> So all I can hope is that one day all your machines, backups and notes
> crash simultaneously, you forget everything you've done before in this
> area, have to start from scratch again and will publish here what you've
> done to produce a working environment :-(

Assuming I'll have time to publish "everything", yes.

What's in nt/INSTALL is supposed to be the important parts, though; it
got additions as people complained about things I initially left
unsaid.

bug#19989: 25.0.50; Build instructions on Windows

[martin rudalics]

 > Assuming I'll have time to publish "everything", yes.

You will because you've just experienced how hard it is to do
"everything" without prior knowledge.

 > What's in nt/INSTALL is supposed to be the important parts, though; it
 > got additions as people complained about things I initially left
 > unsaid.

The problem is that most users are trying to be clever.  At least I did
and AFAICT Ilya did too.  That's of no help.  What's really needed is a
stubborn, dense person who complains immediately when something doesn't
work out as written in INSTALL.

martin, sadly missing Juanma's assistance here

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Sat, Mar 07, 2015 at 11:28:23AM +0100, martin rudalics wrote:
> The problem is that most users are trying to be clever.  At least I did
> and AFAICT Ilya did too.

Yes — the first 8 times.  The last try was by following the
instructions literally (as close as I can after 9 hours of
unsuccessful trying).

>  That's of no help.  What's really needed is a
> stubborn, dense person who complains immediately when something doesn't
> work out as written in INSTALL.

This is exactly what I do.

Ilya

bug#19989: 25.0.50; Build instructions on Windows

[martin rudalics]

 >> The problem is that most users are trying to be clever.  At least I did
 >> and AFAICT Ilya did too.
 >
 > Yes — the first 8 times.  The last try was by following the
 > instructions literally (as close as I can after 9 hours of
 > unsuccessful trying).
 >
 >>   That's of no help.  What's really needed is a
 >> stubborn, dense person who complains immediately when something doesn't
 >> work out as written in INSTALL.
 >
 > This is exactly what I do.

You didn't.  Otherwise, you would have started right away "by following
the instructions literally".  And an important guideline is: Never do
anything extraneous when following INSTALL instructions.  Unfortunately,
installers likes those for mingw/msys offer too many pitfalls in this
area.  Especially when resolving dependencies.

martin

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Sun, Mar 08, 2015 at 11:04:46AM +0100, martin rudalics wrote:
> >> The problem is that most users are trying to be clever.  At least I did
> >> and AFAICT Ilya did too.
> >
> > Yes — the first 8 times.  The last try was by following the
> > instructions literally (as close as I can after 9 hours of
> > unsuccessful trying).
> >
> >>   That's of no help.  What's really needed is a
> >> stubborn, dense person who complains immediately when something doesn't
> >> work out as written in INSTALL.
> >
> > This is exactly what I do.
> 
> You didn't.

I disagree — and I believe I know more about what I did or did not than you.

> Otherwise, you would have started right away "by following
> the instructions literally".

Sorry, I can make no sense out of this “sillogism”.

Ilya

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Fri, Mar 06, 2015 at 10:29:12AM +0200, Eli Zaretskii wrote:
> > > > > > FWIW, the 2nd issue sounds to me like an installation mistake of some
> > > > > > kind (did you install MinGW inside the MSYS tree, by chance?).
> > > > 
> > > > How would I know?
> > > 
> > > You could look at the directory hierarchy that got created.
> > 
> > *This* I did — and I reported the result in my initial message (quoted
> > below).  This does not answer your question.
> 
> It doesn't answer the question, indeed, because you didn't say where
> MinGW programs are, only what PATH you see in the MSYS shell window.

I think I did.  What makes you think I did not?  See

> > > > The result:
> > > >   FOO/bin		- contains gcc executables etc
> > > >   FOO/msys/1.0/		- contains msys
> > > >   FOO/msys/1.0/bin	- contains msys executables

Additionally relevant:


> And the PATH you reported was not exactly what you saw, AFAIU, at
> least that's what follows from the "(essentially)
> FOO/msys/1.0/mingw/bin" part.

The PATH I saw was

  .:/usr/local/bin:/mingw/bin:/bin:/usr/bin
  .:/usr/local/bin:/mingw/bin:/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.

(depending on settings of PATH before starting `bash --login'; and the
dependence is NOT increasing!  The latter is with empty PATH at start,
the former is with [essentially] /bin at start).

> > > > I just ran mingw-get (as described), and set
> > > > install directory ( = FOO) once.
> > > 
> > > Did you select the same install directory for MinGW and for MSYS?
> > 
> > AFAIR, there was no “install directory ‘for”’.  Only “install directory”.
> 
> I'm asking if they share the same directory tree.  Can you show the
> entire tree, e.g. by running 'find -type d'?

Appended.

> > > But then there's no problem, because missing directories on PATH do no
> > > harm.
> > 
> > Of course they do.  configure did not work (since the gcc found on
> > path was not MINGW one).
> 
> So that's the problem: you installed the MSYS GCC (and probably the
> whole MSYS development environment), something one shouldn't do for
> building MinGW programs.  The MSYS GCC and development environment is
> for developing MSYS programs, like the MSYS Bash etc. -- you don't
> want and don't need that.

Are we again following the same loop?!  Let me repeat it: stop
pretending that I *installed* anything.  Think about it this way: I
just followed instructions in nt/INSTALL.

> > > The binaries are in /bin, and it is on PATH, so there should be
> > > no problem; there isn't one in my installation.
> > 
> > Are you joking?!  What do you think is a reason for filing bug
> > reports?  I followed instructions, AND GOT PROBLEMS!
> 
> Well, now I at least understand the reason for your problems: an extra
> development environment that gets in your way.  I didn't understand
> that before, sorry for being too stupid.

Do not think so.  This was just a secondary problem, which I even did
not mention in my initial bug report.

The main problem is that the mingw development environment is not
available when one follows the instructions in nt/INSTALL.  One needs
to manually install an extra package, AND make a symlink to make it
working.

> > Thanks!  But did I ask for that?  This is a bug report, not a cry for
> > help.
> 
> I don't think it's a bug report about Emacs.  Your development
> environment was botched (and maybe still is, if you didn't uninstall
> the MSYS GCC).

If you think so, then you are wrong. 

> > > > BTW: you reminded me: there is another bug in Emacs build — this one
> > > > purely in Emacs.  My default PATH accesses a complete cygwin
> > > > installation
> > 
> > > How does Cygwin enter this equation?  Do you have both Cygwin and
> > > MinGW/MSYS installed?
> > 
> > I have tens of environment installed.  cygwin is on PATH.
> 
> I suggest to remove it.

Hmm, looks like you forgot what was written in the part you trimmed
away.  As I said, starting with an empty PATH fixes things.

> > >  My advice is to have MSYS in separate tree from MinGW,
> > 
> > Is this advice in nt/INSTALL?
> 
> Yes:
> 
>   MSYS packages should be installed in a separate tree from MinGW.
>   For example, use D:\MSYS or D:\usr\MSYS as the top-level directory
>   from which you unpack all of the MSYS packages.

Irrelevant.  I did not unpack anything.  You are quoting a different
section.

>   Do NOT add the MSYS bin directory to your Windows Path!  Only the
>   MinGW bin directory should be on Path.  When you install MSYS, it
>   creates a shortcut on your desktop that invokes the MSYS Bash shell
>   in a Command Prompt window; that shell is already set up so that the
>   MSYS bin directory is on PATH ahead of any other directory.  Thus,
>   Bash will find MSYS executables first, which is exactly what you
>   need.

I have no idea what you are talking about.  (I won’t let unknown
programs touch my desktop.)  I was starting bash as

  set path=K:\get\emacs-build\mingw-get\msys\1.0\bin&& bash --login

This sets PATH as in the first example above.  (The second one is with
the empty PATH.  Same difference!)

> > It was not in *MY* $PATH.  It was in the $PATH created by /etc/profile
> > which was created following instructions in nt/INSTALL.
> 
> /etc/profile just takes your PATH and prepends a few directories to
> it, that's all.

Are we again going along this loop?  How the user following
instructions in nt/INSTALL would know this?

> > > It is next to impossible to have
> > > the Posix configure scripts distinguish between foo.exe or foo.h that
> > > are for Cygwin and their namesakes for MinGW.
> > 
> > For foo.exe — one does not care.  For foo.h — one compiles and runs a
> > simple program.
> 
> See above: you forget the DLLs, for which Windows has quite a
> convoluted search algorithm.

How do I forget it?  If the program runs, headers are fine.

> The other part is Cygwin; if you want to keep it on PATH, and you know
> what you are doing, fine.  It's not the job of nt/INSTALL to tell
> users how to configure their systems to avoid future trouble.

It IS its job to give instructions how to compile Emacs, is not it?

Ilya

=======================================================

.
./bin
./include
./include/ddk
./include/gdiplus
./include/GL
./include/libltdl
./include/parts
./include/sys
./lib
./lib/gcc
./lib/gcc/mingw32
./lib/gcc/mingw32/4.8.1
./lib/gcc/mingw32/4.8.1/include
./lib/gcc/mingw32/4.8.1/include/ssp
./lib/gcc/mingw32/4.8.1/include-fixed
./lib/gcc/mingw32/4.8.1/install-tools
./lib/gcc/mingw32/4.8.1/install-tools/include
./lib/gettext
./libexec
./libexec/gcc
./libexec/gcc/mingw32
./libexec/gcc/mingw32/4.8.1
./libexec/gcc/mingw32/4.8.1/install-tools
./libexec/mingw-get
./mingw32
./mingw32/bin
./mingw32/include
./mingw32/lib
./mingw32/lib/gcc
./mingw32/lib/gcc/mingw32
./mingw32/lib/gcc/mingw32/4.8.1
./mingw32/lib/gcc/mingw32/4.8.1/include
./mingw32/lib/gcc/mingw32/4.8.1/include/ssp
./mingw32/lib/gcc/mingw32/4.8.1/include-fixed
./mingw32/lib/gcc/mingw32/4.8.1/install-tools
./mingw32/lib/gcc/mingw32/4.8.1/install-tools/include
./mingw32/lib/ldscripts
./mingw32/libexec
./mingw32/libexec/gcc
./mingw32/libexec/gcc/mingw32
./mingw32/libexec/gcc/mingw32/4.8.1
./mingw32/libexec/gcc/mingw32/4.8.1/install-tools
./msys
./msys/1.0
./msys/1.0/bin
./msys/1.0/etc
./msys/1.0/etc/ssh
./msys/1.0/home
./msys/1.0/home/Vera
./msys/1.0/home/Vera/.ssh
./msys/1.0/include
./msys/1.0/lib
./msys/1.0/lib/openssl
./msys/1.0/lib/openssl/engines-1.0.0
./msys/1.0/lib/perl5
./msys/1.0/lib/perl5/5.8
./msys/1.0/lib/perl5/5.8/Attribute
./msys/1.0/lib/perl5/5.8/auto
./msys/1.0/lib/perl5/5.8/auto/POSIX
./msys/1.0/lib/perl5/5.8/auto/POSIX/SigAction
./msys/1.0/lib/perl5/5.8/B
./msys/1.0/lib/perl5/5.8/Carp
./msys/1.0/lib/perl5/5.8/CGI
./msys/1.0/lib/perl5/5.8/CGI/eg
./msys/1.0/lib/perl5/5.8/Class
./msys/1.0/lib/perl5/5.8/CPAN
./msys/1.0/lib/perl5/5.8/DBM_Filter
./msys/1.0/lib/perl5/5.8/Devel
./msys/1.0/lib/perl5/5.8/Digest
./msys/1.0/lib/perl5/5.8/Encode
./msys/1.0/lib/perl5/5.8/Encode/CN
./msys/1.0/lib/perl5/5.8/Encode/JP
./msys/1.0/lib/perl5/5.8/Encode/KR
./msys/1.0/lib/perl5/5.8/Encode/MIME
./msys/1.0/lib/perl5/5.8/Encode/MIME/Header
./msys/1.0/lib/perl5/5.8/Encode/Unicode
./msys/1.0/lib/perl5/5.8/Exporter
./msys/1.0/lib/perl5/5.8/ExtUtils
./msys/1.0/lib/perl5/5.8/ExtUtils/Command
./msys/1.0/lib/perl5/5.8/ExtUtils/Constant
./msys/1.0/lib/perl5/5.8/ExtUtils/Liblist
./msys/1.0/lib/perl5/5.8/ExtUtils/MakeMaker
./msys/1.0/lib/perl5/5.8/File
./msys/1.0/lib/perl5/5.8/File/Spec
./msys/1.0/lib/perl5/5.8/Filter
./msys/1.0/lib/perl5/5.8/Getopt
./msys/1.0/lib/perl5/5.8/Hash
./msys/1.0/lib/perl5/5.8/I18N
./msys/1.0/lib/perl5/5.8/I18N/LangTags
./msys/1.0/lib/perl5/5.8/IO
./msys/1.0/lib/perl5/5.8/IO/Socket
./msys/1.0/lib/perl5/5.8/IPC
./msys/1.0/lib/perl5/5.8/List
./msys/1.0/lib/perl5/5.8/Locale
./msys/1.0/lib/perl5/5.8/Locale/Maketext
./msys/1.0/lib/perl5/5.8/Math
./msys/1.0/lib/perl5/5.8/Math/BigFloat
./msys/1.0/lib/perl5/5.8/Math/BigInt
./msys/1.0/lib/perl5/5.8/Memoize
./msys/1.0/lib/perl5/5.8/msys
./msys/1.0/lib/perl5/5.8/msys/auto
./msys/1.0/lib/perl5/5.8/msys/auto/attrs
./msys/1.0/lib/perl5/5.8/msys/auto/B
./msys/1.0/lib/perl5/5.8/msys/auto/B/C
./msys/1.0/lib/perl5/5.8/msys/auto/ByteLoader
./msys/1.0/lib/perl5/5.8/msys/auto/Cwd
./msys/1.0/lib/perl5/5.8/msys/auto/Data
./msys/1.0/lib/perl5/5.8/msys/auto/Data/Dumper
./msys/1.0/lib/perl5/5.8/msys/auto/Devel
./msys/1.0/lib/perl5/5.8/msys/auto/Devel/DProf
./msys/1.0/lib/perl5/5.8/msys/auto/Devel/Peek
./msys/1.0/lib/perl5/5.8/msys/auto/Devel/PPPort
./msys/1.0/lib/perl5/5.8/msys/auto/Digest
./msys/1.0/lib/perl5/5.8/msys/auto/Digest/MD5
./msys/1.0/lib/perl5/5.8/msys/auto/DynaLoader
./msys/1.0/lib/perl5/5.8/msys/auto/Encode
./msys/1.0/lib/perl5/5.8/msys/auto/Encode/Byte
./msys/1.0/lib/perl5/5.8/msys/auto/Encode/CN
./msys/1.0/lib/perl5/5.8/msys/auto/Encode/EBCDIC
./msys/1.0/lib/perl5/5.8/msys/auto/Encode/JP
./msys/1.0/lib/perl5/5.8/msys/auto/Encode/KR
./msys/1.0/lib/perl5/5.8/msys/auto/Encode/Symbol
./msys/1.0/lib/perl5/5.8/msys/auto/Encode/TW
./msys/1.0/lib/perl5/5.8/msys/auto/Encode/Unicode
./msys/1.0/lib/perl5/5.8/msys/auto/Fcntl
./msys/1.0/lib/perl5/5.8/msys/auto/File
./msys/1.0/lib/perl5/5.8/msys/auto/File/Glob
./msys/1.0/lib/perl5/5.8/msys/auto/Filter
./msys/1.0/lib/perl5/5.8/msys/auto/Filter/Util
./msys/1.0/lib/perl5/5.8/msys/auto/Filter/Util/Call
./msys/1.0/lib/perl5/5.8/msys/auto/GDBM_File
./msys/1.0/lib/perl5/5.8/msys/auto/IO
./msys/1.0/lib/perl5/5.8/msys/auto/List
./msys/1.0/lib/perl5/5.8/msys/auto/List/Util
./msys/1.0/lib/perl5/5.8/msys/auto/MIME
./msys/1.0/lib/perl5/5.8/msys/auto/MIME/Base64
./msys/1.0/lib/perl5/5.8/msys/auto/NDBM_File
./msys/1.0/lib/perl5/5.8/msys/auto/ODBM_File
./msys/1.0/lib/perl5/5.8/msys/auto/Opcode
./msys/1.0/lib/perl5/5.8/msys/auto/PerlIO
./msys/1.0/lib/perl5/5.8/msys/auto/PerlIO/encoding
./msys/1.0/lib/perl5/5.8/msys/auto/PerlIO/scalar
./msys/1.0/lib/perl5/5.8/msys/auto/PerlIO/via
./msys/1.0/lib/perl5/5.8/msys/auto/POSIX
./msys/1.0/lib/perl5/5.8/msys/auto/re
./msys/1.0/lib/perl5/5.8/msys/auto/sdbm
./msys/1.0/lib/perl5/5.8/msys/auto/SDBM_File
./msys/1.0/lib/perl5/5.8/msys/auto/Socket
./msys/1.0/lib/perl5/5.8/msys/auto/Storable
./msys/1.0/lib/perl5/5.8/msys/auto/Sys
./msys/1.0/lib/perl5/5.8/msys/auto/Sys/Hostname
./msys/1.0/lib/perl5/5.8/msys/auto/Sys/Syslog
./msys/1.0/lib/perl5/5.8/msys/auto/threads
./msys/1.0/lib/perl5/5.8/msys/auto/threads/shared
./msys/1.0/lib/perl5/5.8/msys/auto/Time
./msys/1.0/lib/perl5/5.8/msys/auto/Time/HiRes
./msys/1.0/lib/perl5/5.8/msys/auto/Unicode
./msys/1.0/lib/perl5/5.8/msys/auto/Unicode/Normalize
./msys/1.0/lib/perl5/5.8/msys/auto/Win32CORE
./msys/1.0/lib/perl5/5.8/msys/auto/XS
./msys/1.0/lib/perl5/5.8/msys/auto/XS/APItest
./msys/1.0/lib/perl5/5.8/msys/auto/XS/Typemap
./msys/1.0/lib/perl5/5.8/msys/B
./msys/1.0/lib/perl5/5.8/msys/CORE
./msys/1.0/lib/perl5/5.8/msys/Data
./msys/1.0/lib/perl5/5.8/msys/Devel
./msys/1.0/lib/perl5/5.8/msys/Digest
./msys/1.0/lib/perl5/5.8/msys/Encode
./msys/1.0/lib/perl5/5.8/msys/File
./msys/1.0/lib/perl5/5.8/msys/Filter
./msys/1.0/lib/perl5/5.8/msys/Filter/Util
./msys/1.0/lib/perl5/5.8/msys/IO
./msys/1.0/lib/perl5/5.8/msys/MIME
./msys/1.0/lib/perl5/5.8/msys/PerlIO
./msys/1.0/lib/perl5/5.8/msys/Sys
./msys/1.0/lib/perl5/5.8/msys/threads
./msys/1.0/lib/perl5/5.8/msys/Time
./msys/1.0/lib/perl5/5.8/msys/Unicode
./msys/1.0/lib/perl5/5.8/msys/XS
./msys/1.0/lib/perl5/5.8/Net
./msys/1.0/lib/perl5/5.8/Net/FTP
./msys/1.0/lib/perl5/5.8/PerlIO
./msys/1.0/lib/perl5/5.8/PerlIO/via
./msys/1.0/lib/perl5/5.8/Pod
./msys/1.0/lib/perl5/5.8/Pod/Perldoc
./msys/1.0/lib/perl5/5.8/Pod/Text
./msys/1.0/lib/perl5/5.8/pods
./msys/1.0/lib/perl5/5.8/Scalar
./msys/1.0/lib/perl5/5.8/Search
./msys/1.0/lib/perl5/5.8/Term
./msys/1.0/lib/perl5/5.8/Test
./msys/1.0/lib/perl5/5.8/Test/Builder
./msys/1.0/lib/perl5/5.8/Test/Builder/Tester
./msys/1.0/lib/perl5/5.8/Test/Harness
./msys/1.0/lib/perl5/5.8/Text
./msys/1.0/lib/perl5/5.8/Thread
./msys/1.0/lib/perl5/5.8/Tie
./msys/1.0/lib/perl5/5.8/Time
./msys/1.0/lib/perl5/5.8/Unicode
./msys/1.0/lib/perl5/5.8/Unicode/Collate
./msys/1.0/lib/perl5/5.8/unicore
./msys/1.0/lib/perl5/5.8/unicore/lib
./msys/1.0/lib/perl5/5.8/unicore/lib/bc
./msys/1.0/lib/perl5/5.8/unicore/lib/ccc
./msys/1.0/lib/perl5/5.8/unicore/lib/dt
./msys/1.0/lib/perl5/5.8/unicore/lib/ea
./msys/1.0/lib/perl5/5.8/unicore/lib/gc_sc
./msys/1.0/lib/perl5/5.8/unicore/lib/hst
./msys/1.0/lib/perl5/5.8/unicore/lib/jt
./msys/1.0/lib/perl5/5.8/unicore/lib/lb
./msys/1.0/lib/perl5/5.8/unicore/lib/nt
./msys/1.0/lib/perl5/5.8/unicore/To
./msys/1.0/lib/perl5/5.8/User
./msys/1.0/lib/perl5/5.8/warnings
./msys/1.0/lib/perl5/site_perl
./msys/1.0/lib/perl5/site_perl/5.8
./msys/1.0/lib/perl5/vendor_perl
./msys/1.0/lib/perl5/vendor_perl/5.8
./msys/1.0/lib/perl5/vendor_perl/5.8/Archive
./msys/1.0/lib/perl5/vendor_perl/5.8/Archive/Tar
./msys/1.0/lib/perl5/vendor_perl/5.8/Archive/Zip
./msys/1.0/lib/perl5/vendor_perl/5.8/auto
./msys/1.0/lib/perl5/vendor_perl/5.8/auto/Compress
./msys/1.0/lib/perl5/vendor_perl/5.8/auto/Compress/Zlib
./msys/1.0/lib/perl5/vendor_perl/5.8/auto/Tee
./msys/1.0/lib/perl5/vendor_perl/5.8/Bundle
./msys/1.0/lib/perl5/vendor_perl/5.8/Compress
./msys/1.0/lib/perl5/vendor_perl/5.8/Config
./msys/1.0/lib/perl5/vendor_perl/5.8/CPAN
./msys/1.0/lib/perl5/vendor_perl/5.8/CPAN/Kwalify
./msys/1.0/lib/perl5/vendor_perl/5.8/CPAN/Reporter
./msys/1.0/lib/perl5/vendor_perl/5.8/Devel
./msys/1.0/lib/perl5/vendor_perl/5.8/Devel/Symdump
./msys/1.0/lib/perl5/vendor_perl/5.8/ExtUtils
./msys/1.0/lib/perl5/vendor_perl/5.8/ExtUtils/CBuilder
./msys/1.0/lib/perl5/vendor_perl/5.8/ExtUtils/CBuilder/Platform
./msys/1.0/lib/perl5/vendor_perl/5.8/File
./msys/1.0/lib/perl5/vendor_perl/5.8/File/Copy
./msys/1.0/lib/perl5/vendor_perl/5.8/File/HomeDir
./msys/1.0/lib/perl5/vendor_perl/5.8/HTML
./msys/1.0/lib/perl5/vendor_perl/5.8/HTTP
./msys/1.0/lib/perl5/vendor_perl/5.8/HTTP/Cookies
./msys/1.0/lib/perl5/vendor_perl/5.8/HTTP/Headers
./msys/1.0/lib/perl5/vendor_perl/5.8/HTTP/Request
./msys/1.0/lib/perl5/vendor_perl/5.8/IO
./msys/1.0/lib/perl5/vendor_perl/5.8/IO/Compress
./msys/1.0/lib/perl5/vendor_perl/5.8/IO/Compress/Adapter
./msys/1.0/lib/perl5/vendor_perl/5.8/IO/Compress/Base
./msys/1.0/lib/perl5/vendor_perl/5.8/IO/Compress/Gzip
./msys/1.0/lib/perl5/vendor_perl/5.8/IO/Compress/Zip
./msys/1.0/lib/perl5/vendor_perl/5.8/IO/Compress/Zlib
./msys/1.0/lib/perl5/vendor_perl/5.8/IO/Uncompress
./msys/1.0/lib/perl5/vendor_perl/5.8/IO/Uncompress/Adapter
./msys/1.0/lib/perl5/vendor_perl/5.8/IPC
./msys/1.0/lib/perl5/vendor_perl/5.8/IPC/Run3
./msys/1.0/lib/perl5/vendor_perl/5.8/LWP
./msys/1.0/lib/perl5/vendor_perl/5.8/LWP/Authen
./msys/1.0/lib/perl5/vendor_perl/5.8/LWP/Protocol
./msys/1.0/lib/perl5/vendor_perl/5.8/Module
./msys/1.0/lib/perl5/vendor_perl/5.8/Module/Build
./msys/1.0/lib/perl5/vendor_perl/5.8/Module/Build/Platform
./msys/1.0/lib/perl5/vendor_perl/5.8/Module/ScanDeps
./msys/1.0/lib/perl5/vendor_perl/5.8/msys
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Alias
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Archive
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Archive/Tar
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Archive/Zip
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/B
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/B/Generate
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Compress
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Compress/Bzip2
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Compress/Raw
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Compress/Raw/Bzip2
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Compress/Raw/Zlib
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Compress/Zlib
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Config
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Config/Tiny
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/CPAN
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/CPAN/Reporter
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Devel
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Devel/Symdump
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Digest
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Digest/SHA
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/ExtUtils
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/ExtUtils/CBuilder
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/ExtUtils/ParseXS
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/File
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/File/Copy
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/File/Copy/Recursive
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/File/HomeDir
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/File/pushd
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/File/Temp
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/HTML
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/HTML/Parser
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/HTML/Tagset
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/IO
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/IO/CaptureOutput
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/IO/Compress
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/IO/Compress/Base
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/IO/Compress/Bzip2
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/IO/Compress/Zlib
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/IO/String
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/IO/Zlib
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/IPC
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/IPC/Run3
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/LWP
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Math
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Math/BigInt
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Math/BigInt/FastCalc
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/MD5
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Module
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Module/Build
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Module/ScanDeps
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Net
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Net/Telnet
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/PadWalker
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/PAR
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/PAR/Dist
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Pod
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Pod/Coverage
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Pod/Escapes
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Pod/Readme
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Pod/Simple
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Probe
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Probe/Perl
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Regexp
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Regexp/Common
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Tee
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Term
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Term/ReadKey
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Term/ReadLine
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Test
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Test/Pod
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Test/Pod/Coverage
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Test/Reporter
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/URI
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/version
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/version/vxs
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Win32API
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Win32API/File
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/XML
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/XML/LibXML
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/XML/LibXML/Common
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/XML/NamespaceSupport
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/XML/Parser
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/XML/Parser/Expat
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/XML/SAX
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/YAML
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/B
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/Compress
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/Compress/Raw
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/Digest
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/HTML
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/Math
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/Math/BigInt
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/Term
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/version
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/Win32API
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/Win32API/File
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/XML
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/XML/LibXML
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/XML/LibXML/SAX
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/XML/Parser
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/XML/Parser/Encodings
./msys/1.0/lib/perl5/vendor_perl/5.8/msys/XML/Parser/Style
./msys/1.0/lib/perl5/vendor_perl/5.8/Net
./msys/1.0/lib/perl5/vendor_perl/5.8/Net/HTTP
./msys/1.0/lib/perl5/vendor_perl/5.8/PAR
./msys/1.0/lib/perl5/vendor_perl/5.8/Pod
./msys/1.0/lib/perl5/vendor_perl/5.8/Pod/Coverage
./msys/1.0/lib/perl5/vendor_perl/5.8/Pod/Simple
./msys/1.0/lib/perl5/vendor_perl/5.8/Pod/Text
./msys/1.0/lib/perl5/vendor_perl/5.8/Probe
./msys/1.0/lib/perl5/vendor_perl/5.8/Regexp
./msys/1.0/lib/perl5/vendor_perl/5.8/Regexp/Common
./msys/1.0/lib/perl5/vendor_perl/5.8/Regexp/Common/URI
./msys/1.0/lib/perl5/vendor_perl/5.8/Term
./msys/1.0/lib/perl5/vendor_perl/5.8/Term/ReadLine
./msys/1.0/lib/perl5/vendor_perl/5.8/Test
./msys/1.0/lib/perl5/vendor_perl/5.8/Test/Pod
./msys/1.0/lib/perl5/vendor_perl/5.8/Test/Reporter
./msys/1.0/lib/perl5/vendor_perl/5.8/Test/Reporter/Date
./msys/1.0/lib/perl5/vendor_perl/5.8/Test/Reporter/Mail
./msys/1.0/lib/perl5/vendor_perl/5.8/Test/Reporter/Time
./msys/1.0/lib/perl5/vendor_perl/5.8/URI
./msys/1.0/lib/perl5/vendor_perl/5.8/URI/file
./msys/1.0/lib/perl5/vendor_perl/5.8/URI/urn
./msys/1.0/lib/perl5/vendor_perl/5.8/WWW
./msys/1.0/lib/perl5/vendor_perl/5.8/WWW/RobotRules
./msys/1.0/lib/perl5/vendor_perl/5.8/XML
./msys/1.0/lib/perl5/vendor_perl/5.8/XML/SAX
./msys/1.0/lib/perl5/vendor_perl/5.8/XML/SAX/PurePerl
./msys/1.0/lib/perl5/vendor_perl/5.8/XML/SAX/PurePerl/Reader
./msys/1.0/lib/perl5/vendor_perl/5.8/YAML
./msys/1.0/lib/perl5/vendor_perl/5.8/YAML/Dumper
./msys/1.0/lib/perl5/vendor_perl/5.8/YAML/Loader
./msys/1.0/postinstall
./msys/1.0/sbin
./msys/1.0/sbin/awk
./msys/1.0/share
./msys/1.0/share/aclocal
./msys/1.0/share/autogen
./msys/1.0/share/awk
./msys/1.0/share/bison
./msys/1.0/share/bison/m4sugar
./msys/1.0/share/bison/xslt
./msys/1.0/share/cvs
./msys/1.0/share/cvs/contrib
./msys/1.0/share/doc
./msys/1.0/share/doc/MSYS
./msys/1.0/share/guile
./msys/1.0/share/guile/1.8
./msys/1.0/share/guile/1.8/ice-9
./msys/1.0/share/guile/1.8/ice-9/debugger
./msys/1.0/share/guile/1.8/ice-9/debugging
./msys/1.0/share/guile/1.8/lang
./msys/1.0/share/guile/1.8/lang/elisp
./msys/1.0/share/guile/1.8/lang/elisp/internals
./msys/1.0/share/guile/1.8/lang/elisp/primitives
./msys/1.0/share/guile/1.8/oop
./msys/1.0/share/guile/1.8/oop/goops
./msys/1.0/share/guile/1.8/scripts
./msys/1.0/share/guile/1.8/srfi
./msys/1.0/share/locale
./msys/1.0/share/locale/da
./msys/1.0/share/locale/da/LC_MESSAGES
./msys/1.0/share/locale/de
./msys/1.0/share/locale/de/LC_MESSAGES
./msys/1.0/share/locale/eo
./msys/1.0/share/locale/eo/LC_MESSAGES
./msys/1.0/share/locale/es
./msys/1.0/share/locale/es/LC_MESSAGES
./msys/1.0/share/locale/fr
./msys/1.0/share/locale/fr/LC_MESSAGES
./msys/1.0/share/locale/hu
./msys/1.0/share/locale/hu/LC_MESSAGES
./msys/1.0/share/locale/nb
./msys/1.0/share/locale/nb/LC_MESSAGES
./msys/1.0/share/locale/nl
./msys/1.0/share/locale/nl/LC_MESSAGES
./msys/1.0/share/locale/pl
./msys/1.0/share/locale/pl/LC_MESSAGES
./msys/1.0/share/locale/pt_BR
./msys/1.0/share/locale/pt_BR/LC_MESSAGES
./msys/1.0/share/locale/ru
./msys/1.0/share/locale/ru/LC_MESSAGES
./msys/1.0/share/locale/sr
./msys/1.0/share/locale/sr/LC_MESSAGES
./msys/1.0/share/locale/uk
./msys/1.0/share/locale/uk/LC_MESSAGES
./msys/1.0/share/locale/vi
./msys/1.0/share/locale/vi/LC_MESSAGES
./msys/1.0/share/locale/zh_TW
./msys/1.0/share/locale/zh_TW/LC_MESSAGES
./msys/1.0/share/misc
./msys/1.0/share/vim
./msys/1.0/share/vim/vim73
./msys/1.0/share/vim/vim73/autoload
./msys/1.0/share/vim/vim73/autoload/xml
./msys/1.0/share/vim/vim73/colors
./msys/1.0/share/vim/vim73/compiler
./msys/1.0/share/vim/vim73/ftplugin
./msys/1.0/share/vim/vim73/indent
./msys/1.0/share/vim/vim73/macros
./msys/1.0/share/vim/vim73/macros/hanoi
./msys/1.0/share/vim/vim73/macros/life
./msys/1.0/share/vim/vim73/macros/maze
./msys/1.0/share/vim/vim73/macros/urm
./msys/1.0/share/vim/vim73/plugin
./msys/1.0/share/vim/vim73/print
./msys/1.0/share/vim/vim73/spell
./msys/1.0/share/vim/vim73/syntax
./msys/1.0/share/vim/vim73/tools
./msys/1.0/share/vim/vim73/tutor
./msys/1.0/var
./msys/1.0/var/empty
./msys/1.0/var/run
./msys/1.0/var/ssl
./msys/1.0/var/ssl/certs
./msys/1.0/var/ssl/certs/demo
./msys/1.0/var/ssl/certs/expired
./msys/1.0/var/ssl/misc
./msys/1.0/var/ssl/private
./msys/1.0/var/ssl/rootcerts
./share
./share/aclocal
./share/aclocal-1.10
./share/aclocal-1.11
./share/aclocal-1.4
./share/aclocal-1.5
./share/aclocal-1.6
./share/aclocal-1.7
./share/aclocal-1.8
./share/aclocal-1.9
./share/autoconf
./share/autoconf/autoconf
./share/autoconf/Autom4te
./share/autoconf/autoscan
./share/autoconf/autotest
./share/autoconf/m4sugar
./share/automake-1.10
./share/automake-1.10/am
./share/automake-1.10/Automake
./share/automake-1.11
./share/automake-1.11/am
./share/automake-1.11/Automake
./share/automake-1.4
./share/automake-1.5
./share/automake-1.5/am
./share/automake-1.5/Automake
./share/automake-1.6
./share/automake-1.6/am
./share/automake-1.6/Automake
./share/automake-1.7
./share/automake-1.7/am
./share/automake-1.7/Automake
./share/automake-1.8
./share/automake-1.8/am
./share/automake-1.8/Automake
./share/automake-1.9
./share/automake-1.9/am
./share/automake-1.9/Automake
./share/autotools
./share/doc
./share/doc/gcc
./share/doc/gcc/4.8.1
./share/doc/gcc/4.8.1/gcc
./share/doc/gcc/4.8.1/include
./share/doc/gcc/4.8.1/libffi
./share/doc/gcc/4.8.1/libiberty
./share/doc/gcc/4.8.1/libquadmath
./share/doc/gcc/4.8.1/libsanitizer
./share/doc/gcc/4.8.1/zlib
./share/doc/gcc/4.8.1/zlib/contrib
./share/doc/gcc/4.8.1/zlib/contrib/dotzlib
./share/doc/MinGW
./share/doc/mingw-get
./share/gdb
./share/gdb/python
./share/gdb/python/gdb
./share/gdb/python/gdb/command
./share/gdb/python/gdb/function
./share/gdb/syscalls
./share/gettext
./share/gettext/intl
./share/gettext/po
./share/libtool
./share/libtool/config
./share/libtool/libltdl
./share/libtool/libltdl/libltdl
./share/libtool/libltdl/loaders
./share/locale
./share/locale/be
./share/locale/be/LC_MESSAGES
./share/locale/bg
./share/locale/bg/LC_MESSAGES
./share/locale/ca
./share/locale/ca/LC_MESSAGES
./share/locale/cs
./share/locale/cs/LC_MESSAGES
./share/locale/da
./share/locale/da/LC_MESSAGES
./share/locale/de
./share/locale/de/LC_MESSAGES
./share/locale/el
./share/locale/el/LC_MESSAGES
./share/locale/en@boldquot
./share/locale/en@boldquot/LC_MESSAGES
./share/locale/en@quot
./share/locale/en@quot/LC_MESSAGES
./share/locale/eo
./share/locale/eo/LC_MESSAGES
./share/locale/es
./share/locale/es/LC_MESSAGES
./share/locale/et
./share/locale/et/LC_MESSAGES
./share/locale/eu
./share/locale/eu/LC_MESSAGES
./share/locale/fi
./share/locale/fi/LC_MESSAGES
./share/locale/fr
./share/locale/fr/LC_MESSAGES
./share/locale/ga
./share/locale/ga/LC_MESSAGES
./share/locale/gl
./share/locale/gl/LC_MESSAGES
./share/locale/hr
./share/locale/hr/LC_MESSAGES
./share/locale/id
./share/locale/id/LC_MESSAGES
./share/locale/it
./share/locale/it/LC_MESSAGES
./share/locale/ja
./share/locale/ja/LC_MESSAGES
./share/locale/ko
./share/locale/ko/LC_MESSAGES
./share/locale/nb
./share/locale/nb/LC_MESSAGES
./share/locale/nl
./share/locale/nl/LC_MESSAGES
./share/locale/nn
./share/locale/nn/LC_MESSAGES
./share/locale/pa
./share/locale/pa/LC_MESSAGES
./share/locale/pl
./share/locale/pl/LC_MESSAGES
./share/locale/pt
./share/locale/pt/LC_MESSAGES
./share/locale/pt_BR
./share/locale/pt_BR/LC_MESSAGES
./share/locale/ro
./share/locale/ro/LC_MESSAGES
./share/locale/ru
./share/locale/ru/LC_MESSAGES
./share/locale/sk
./share/locale/sk/LC_MESSAGES
./share/locale/sl
./share/locale/sl/LC_MESSAGES
./share/locale/sr
./share/locale/sr/LC_MESSAGES
./share/locale/sv
./share/locale/sv/LC_MESSAGES
./share/locale/tr
./share/locale/tr/LC_MESSAGES
./share/locale/uk
./share/locale/uk/LC_MESSAGES
./share/locale/vi
./share/locale/vi/LC_MESSAGES
./share/locale/zh_CN
./share/locale/zh_CN/LC_MESSAGES
./share/locale/zh_HK
./share/locale/zh_HK/LC_MESSAGES
./share/locale/zh_TW
./share/locale/zh_TW/LC_MESSAGES
./var
./var/cache
./var/cache/mingw-get
./var/cache/mingw-get/data
./var/cache/mingw-get/data/.in-transit
./var/cache/mingw-get/packages
./var/cache/mingw-get/packages/.in-transit
./var/lib
./var/lib/mingw-get
./var/lib/mingw-get/data

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

If you want to suggest a specific change for nt/INSTALL, please do.

Otherwise, I will close this bug as wont-fix.  I had enough of your
abuse.

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Fri, Mar 06, 2015 at 12:33:28PM +0200, Eli Zaretskii wrote:
> If you want to suggest a specific change for nt/INSTALL, please do.

I, essentially, did — in my initial bug report.  I would try again — later.

> Otherwise, I will close this bug as wont-fix.

Up to you.

>  I had enough of your abuse.

How would you call a repeated twisting of a bug report into a cry for
help?

Yours,
Ilya

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Fri, 06 Mar 2015 10:29:12 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 19989@debbugs.gnu.org
> 
> > Of course they do.  configure did not work (since the gcc found on
> > path was not MINGW one).
> 
> So that's the problem: you installed the MSYS GCC (and probably the
> whole MSYS development environment), something one shouldn't do for
> building MinGW programs.

Or maybe I again misunderstood, and the GCC found first on PATH was
the Cygwin GCC?  Then that'd be the "don't mix Cygwin with MinGW in
the same session" part of my advice again.

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Fri, Mar 06, 2015 at 12:08:00PM +0200, Eli Zaretskii wrote:
> > So that's the problem: you installed the MSYS GCC (and probably the
> > whole MSYS development environment), something one shouldn't do for
> > building MinGW programs.
> 
> Or maybe I again misunderstood, and the GCC found first on PATH was
> the Cygwin GCC?  Then that'd be the "don't mix Cygwin with MinGW in
> the same session" part of my advice again.

Yes, you again misunderstood.  But the last paragraph of yours is
irrelevant.  The issue of another gcc on PATH is not important.  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.
 
(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).

Ilya

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Fri, 6 Mar 2015 17:35:02 -0800
> From: Ilya Zakharevich <ilya@math.berkeley.edu>
> Cc: 19989@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.

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Sat, Mar 07, 2015 at 11:04:41AM +0200, Eli Zaretskii wrote:
> So, let's try one more time, and this time try to provide full answers
> with all the details:

Thanks for providing the instructions.  I’ll try to answer your
questions when possible.

> And if what you intended is suggest that users be …

No thanks for putting words in my mouth.

> links can create.  If there is a problem, we will have to find a way
> of avoiding it without such kludges.

I’m pleased to hear this!

> 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.

Thanks for not being secretive about how your mind works.  I hope you
would cope with this attitude.

Yours,
Ilya

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Sat, 7 Mar 2015 22:14:13 -0800
> From: Ilya Zakharevich <ilya@math.berkeley.edu>
> Cc: 19989@debbugs.gnu.org
> 
> On Sat, Mar 07, 2015 at 11:04:41AM +0200, Eli Zaretskii wrote:
> > So, let's try one more time, and this time try to provide full answers
> > with all the details:
> 
> Thanks for providing the instructions.  I’ll try to answer your
> questions when possible.

Thanks, I'm eagerly waiting for that.

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Sat, Mar 07, 2015 at 11:04:41AM +0200, Eli Zaretskii wrote:
> So, let's try one more time, and this time try to provide full answers
> with all the details:

I do not have a time machine.  The actual install was made more than a
month ago.  I made some notes — and everything in these notes was
in my report.  The rest of historical information is gone.

>  . In which directory do you have the MinGW gcc.exe?

It is in
      FOO/bin/gcc.exe
When bash --login is started with an empty path, this one is on
      /mingw/bin/gcc.exe
(due to my symlink of MSYS’s /mingw to the native directory FOO).

>  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.

Irrelevant.  You may think that FOO is f:/oo — it would be least
confusing.  Otherwise, if you want to confuse yourself MUCH more, FOO
is
	k:/get/emacs-build/mingw-get

>  . In which directory do you have the "wrong" gcc.exe?  Please provide
>    the same details about that as for the MinGW gcc.exe.

This IS absolutely irrelevant.  Moreover, it was in many different
directories on different tries.  All that is important is that it was
on PATH when
    bash --login
was started.

>  . What is the full value of PATH, in MSYS Bash and in the Windows
>    cmd.exe shell?

When started with empty PATH, the first one is, as reported,
  .:/usr/local/bin:/mingw/bin:/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
The second one was, obviously, empty.

I won’t supply my default PATH for obvious reasons — and since it has
no bearing on half of the cases reported (empty PATH), and is
practically guaranteed to be irrelevant for the other half.

>  . 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.)

Inside FOO, the following directories have .h files:
    ./include/
    ./include/GL/
    ./include/ddk/
    ./include/gdiplus/
    ./include/libltdl/
    ./include/parts/
    ./include/sys/
    ./lib/gcc/mingw32/4.8.1/include-fixed/
    ./lib/gcc/mingw32/4.8.1/include/
    ./lib/gcc/mingw32/4.8.1/include/ssp/
    ./lib/gcc/mingw32/4.8.1/install-tools/
    ./lib/gcc/mingw32/4.8.1/install-tools/include/
    ./mingw32/include/
    ./mingw32/lib/gcc/mingw32/4.8.1/include-fixed/
    ./mingw32/lib/gcc/mingw32/4.8.1/include/
    ./mingw32/lib/gcc/mingw32/4.8.1/include/ssp/
    ./mingw32/lib/gcc/mingw32/4.8.1/install-tools/
    ./mingw32/lib/gcc/mingw32/4.8.1/install-tools/include/
    ./msys/1.0/include/
    ./msys/1.0/lib/perl5/5.8/Encode/
    ./msys/1.0/lib/perl5/5.8/msys/CORE/
    ./share/autoconf/
    ./share/gettext/
    ./share/gettext/intl/
    ./share/libtool/libltdl/
    ./share/libtool/libltdl/libltdl/

Likewise for .a files (removing excessive Perl “auto” subdirectories):

    ./lib/
    ./lib/gcc/mingw32/4.8.1/
    ./libexec/gcc/mingw32/4.8.1/
    ./mingw32/lib/
    ./mingw32/lib/gcc/mingw32/4.8.1/
    ./mingw32/libexec/gcc/mingw32/4.8.1/
    ./msys/1.0/lib/
    ./msys/1.0/lib/perl5/5.8/msys/CORE/
    ./msys/1.0/lib/perl5/5.8/msys/auto/B/
    ./msys/1.0/lib/perl5/vendor_perl/5.8/msys/auto/Alias/

>  . 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.

N/A

>  . 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.

As reported, the only one for which I needed to put a manual checkmark
was mingw32-base.  The rest of info is gone.

>  . 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.

This info is gone (reliable one).  AFAICR, the only choice was the
install directory (FOO above).

===========================================

If I can squeeze it into a few minutes, I may try to redo installing
via mingw-get on a pristine computer (need to borrow it).

Ilya

bug#19989: 25.0.50; Build instructions on Windows

[Eli Zaretskii]

> Date: Sun, 8 Mar 2015 09:04:19 -0700
> From: Ilya Zakharevich <ilya@math.berkeley.edu>
> Cc: 19989@debbugs.gnu.org
> 
> >  . In which directory do you have the MinGW gcc.exe?
> 
> It is in
>       FOO/bin/gcc.exe
> When bash --login is started with an empty path, this one is on
>       /mingw/bin/gcc.exe
> (due to my symlink of MSYS’s /mingw to the native directory FOO).
> 
> >  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.
> 
> Irrelevant.  You may think that FOO is f:/oo — it would be least
> confusing.  Otherwise, if you want to confuse yourself MUCH more, FOO
> is
> 	k:/get/emacs-build/mingw-get
> 
> >  . In which directory do you have the "wrong" gcc.exe?  Please provide
> >    the same details about that as for the MinGW gcc.exe.
> 
> This IS absolutely irrelevant.  Moreover, it was in many different
> directories on different tries.  All that is important is that it was
> on PATH when
>     bash --login
> was started.
> 
> >  . What is the full value of PATH, in MSYS Bash and in the Windows
> >    cmd.exe shell?
> 
> When started with empty PATH, the first one is, as reported,
>   .:/usr/local/bin:/mingw/bin:/bin:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
> The second one was, obviously, empty.
> 
> I won’t supply my default PATH for obvious reasons — and since it has
> no bearing on half of the cases reported (empty PATH), and is
> practically guaranteed to be irrelevant for the other half.

Sigh...  You still don't get it, do you?  You still look at the
information through the broken glass of your (mis)conception of what
happened, and decide what is relevant based on that.  That selective
reporting of important information is precisely what gets in the way
of understanding the issue efficiently and correctly.

If you don't tell me your directories and the full PATH, how am I
supposed to know which one is before the other?  Oh, I could start
asking all these questions one by one, but why should I?  Why couldn't
you provide that information as requested?  You want to obfuscate your
directories for privacy reasons -- be my guest, as long as you do that
consistently, and as long as each real directory is substituted with a
unique replacement string.  How hard can that be?

Also, you only told what was PATH in MSYS when it was empty outside.
Did you ever try without emptying the outside PATH?  If so, was the
directory with the MinGW gcc.exe on that PATH?

(And, btw, how exactly did you invoke Bash "with an empty PATH"?)

> >  . 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.
> 
> As reported, the only one for which I needed to put a manual checkmark
> was mingw32-base.  The rest of info is gone.

This part of the information can be restored if you run mingw-get
again and display the installed packages.  But don't bother, since I
already gleaned that from the list of directories you've shown.

And 2 more questions:

  . What does this command show, when you invoke it in the MSYS Bash
    shell:

     ls -l /etc/fstab*

  . How do you invoke the MSYS Bash? just "bash --login" from cmd.exe
    prompt, or in some other way (desktop shortcut or somesuch)?  If
    through a shortcut, what does the "Target" field of the shortcut's
    Properties say?

bug#19989: 25.0.50; Build instructions on Windows

[Ilya Zakharevich]

On Tue, Mar 03, 2015 at 07:00:09PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 3 Mar 2015 08:34:53 -0800
> > From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
> > 
> > =======================================================
> > 
> > I needed the following changes to build Emacs (when following the
> > instructions in nt/INSTALL):
> >   • mingw-get:
> > 	actually, mingw32-base is not installed by default;
> >         I needed to install it by manually marking it in mingw-get.
> >   • mingw shell sets path to (essentially) FOO/msys/1.0/mingw/bin (here FOO
> >         is the install path), but there is no directory
> >           FOO/msys/1.0/mingw
> >         what is is
> >           FOO/bin
> >     So I needed to make a symbolic link (Windows style required) by
> >     running
> >         mklink /j mingw FOO
> >     in FOO/msys/1.0
> 
> Thanks.
> 
> I suggest to post this to the MinGW mailing list
> <mingw-users@lists.sourceforge.net> first, as what you describe sounds
> like MinGW issues not directly related to building Emacs.  If they say
> that this is "as designed", then we will see about adding something to
> nt/INSTALL to work around this.

I tried.  They require registration (and I exhaused my abilities to
register already more than a decade ago).  If somebody is a member, can
you forward this?

Thanks,
Ilya