Re: [lmi] Cygwin build failure

[Vadim Zeitlin]

On Tue, 30 Apr 2019 01:59:20 +0000 Greg Chicares <address@hidden> wrote:

[...speaking of 32- and 64-bit builds coexistence...]

GC> But they don't both have to be available in the same cygwin instance.
GC> Cygwin allows multiple installations on the same machine

 Interesting, I didn't know this. But even if it's supported, I'm not sure
what do we gain from having 2 Cygwin installations? It seems like an
overkill if the goal is just to avoid the /MinGW_ conflict. It could be
advantageous from the point of view of being simply able to remove the 32
bit Cygwin version after switching to 64 bit one, but OTOH continuing to
have just a single version of Cygwin would seem to be even more
advantageous because nothing would need to be removed in the first place
because everybody could just continue using whichever version of Cygwin
they already have. Or am I wrong in assuming that we can use 32 bit Cygwin
for 64 bit builds as well? I admit I haven't tested it myself, but AFAICS
it should work, shouldn't it?

 My main concern here is that even having 2 Cygwin installations is
perfectly supported, it must still be much rarer than having one of them
and so chances of having some weird problems (which are unfortunately not
unheard of with Cygwin) with them are higher. And then there is also the
issue of human confusion, i.e. it must be relatively easy to accidentally
run 32-bit version instead of 64-bit one or vice versa, while having only a
single version is much less error-prone.


GC> >  Moreover, even 32 bit build fails with 8.1.0, which is the version
GC> > currently installed by install_mingw.make, because currently the compiler
GC> > is not installed in the correct directory and we end up with
GC> > /MinGW_/mingw32/bin/gcc.exe instead of the expected /MinGW_/bin/gcc.exe.
GC> 
GC> What can have gone wrong?
GC> 
GC> $git log --oneline -- install_mingw.make
GC> 9afb0922 Rename "scratch" directories
GC> 74fe75e2 Upgrade to gcc-8.x
GC> bcdd1c61 Terminate all files with a single (not double) newline
GC> 53cea856 Update copyright notices
GC> e3bbb946 Upgrade to gcc-7.3
GC> 45cbda55 Experimentally use 'cp' where 'mv' fails
GC> 
GC> It certainly worked as of the last commit shown, 45cbda55; we know that
GC> because that change was a required workaround for a cygwin problem.
GC> 
GC> The other commits since then seem innocent. Only the most recent one,
GC> 9afb0922, looks like it could possibly be wrong, but I don't see
GC> anything in it that could account for the observed anomaly.

 Me neither, but the copy command copies (recursively) "mingw32"
subdirectory from /MinGW_/ad_hoc to /MinGW_ itself which seems just as
incorrect now as in 45cbda55. In fact, I now wonder if the workaround of
replacing "mv" with "cp" could be just due to using the wrong directory
name in 8a7d87dbdf? I.e. my hypothesis is that this never worked since
switching to MinGW-w64 toolchain in that commit and that the workaround
didn't work neither and that the files just were copied/moved manually to
fix the problem instead. I realize that this seems rather implausible, but
I simply don't see anything else.

GC> Is it possible that the MinGW-w64 project has changed the structure of
GC> the archives it distributes?

 Not since the last 3 years, I've already checked this and they already had
this subdirectory in 7.2 archives. Besides, if they didn't have it, surely
mv/cp command using it as source would have failed, wouldn't it?

 Regards,
VZ