Re: [lmi] Availability of msw gcc binaries

[Vadim Zeitlin]

On Sun, 2 Aug 2020 00:18:28 +0200 I wrote:

Me> On Sat, 1 Aug 2020 20:56:24 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:
Me> 
Me> GC> This would seem to be the canonical MinGW-w64 download page:
Me> GC>   https://downloads.sourceforge.net/mingw-w64
Me> GC> but the latest version there is gcc-8.1.0, which is pretty
Me> GC> old: gcc.gnu.org released 8.1 on 2020-03-04, and they're
Me> GC> already up to 10.2 .
[...]
Me>  I'm not sure, but I think most people use MSYS2, actually: it seems to
Me> have become the de facto standard for building MSW software in Unix-y way
Me> since a couple of years already, e.g. I see it used a lot (and am
Me> considering using it myself) for the CI builds under MSW. I've tested it
Me> myself and I must admit that it's indeed very convenient: it's trivial to
Me> install, completely isolated from the rest of the system, but provides
Me> everything you need to build 99% (or maybe even more, I really didn't find
Me> anything missing) of the stuff. The problem is that it's still a whole new
Me> environment and you need to learn at least a few commands to use its
Me> package system.
Me> 
Me>  If you'd like to avoid this, more recent binaries are available from
Me> http://winlibs.com/ (maintained by someone called Brecht Sanders) and
Me> then there is also the revival of TDM-GCC that I had good experience with
Me> (i.e. much better than with plain MinGW) in the past, see
Me> https://jmeubank.github.io/tdm-gcc/, but it's, of course, a slightly
Me> different compiler, which, perhaps, could be seen as an advantage, but
Me> clearly can be a disadvantage too.
Me> 
Me>  To use exactly the same compiler I'm afraid we have to choose between
Me> uncertain provenance/longevity of winlibs.com and all the extra weight
Me> coming with MSYS2 (but this one should be more future-proof, as it's used
Me> by many projects, including Git, for building their MSW binaries).
Me> 
Me> GC> At any rate, this is just one more reason for migrating
Me> GC> all our development to linux.
Me> 
Me>  This is, of course, also a perfectly reasonable solution.

 Hello,

 I'd like to return to this discussion because we need to move beyond gcc
8.1 in order to use std::filesystem, which doesn't work in the libstdc++
version shipped with this compiler under MSW. It does work with 10.2 (we
tested this) and probably with 9.1 too (at least the bug in 8.1 is supposed
to be fixed there, but I didn't test this personally), but there doesn't
seem to be any reasonable way to make it work with 8.1.

 So what should we do? Should we just continue working on replacing
Boost.Filesystem with std::filesystem in the hope that by the time this is
done, we'll be able to find a compiler with std::filesystem support under
MSW, or would it be better to resolve this question first?

 I'm afraid nothing much has changed since my previous reply 1.5 months ago
(other than winlibs.com binaries have been updated to 10.2), i.e. our
choices are still:

1. Use standalone download from http://winlibs.com/
2. Use MSYS2 environment (which is basically Cygwin replacement from our
   point of view)
3. Don't support building under MSW at all and just use the cross-compiler
   from Debian

 Do you think any of those could be acceptable?

 Thanks,
VZ

pgpuX8cMQhGxG.pgp
Description: PGP signature