Re: [patch] compile: rm -rf -> ftw()+rmdir()+unlink() [Re: [patch] compile: Fix MinGW build]

Kai Tietz
2014-12-18T20:15:06Z

----- Ursprüngliche Mail -----
> > Date: Thu, 18 Dec 2014 18:31:03 +0100
> > From: Jan Kratochvil <jan.kratochvil@redhat.com>
> > Cc: ktietz@redhat.com, sellcey@imgtec.com, brobecker@adacore.com,
> > yao@codesourcery.com, gdb-patches@sourceware.org
> >
> > >From the Fedora point of view MinGW64 32-bit mode seems to be a superset
> > >of
> > MinGW32 so why to care about MinGW32 anymore? Or what do I miss?
>
> That _I_ use MinGW32?

That is actually your problem, isn't it? The mingw-w64 target support ftw, so why not simply allow it for targets providing it, and other targets can be covered by gnulib?
Anyway gnulib is nothing I am concerned in general.

> Seriously, though: from my POV, MinGW64 is not reliable yet to switch
> to it completely, their development still breaks the libraries too
> often, and there are significant backward-incompatible changes now and
> then. The fact that there's no official releases of MinGW64 doesn't
> help.

Seriously answering this ...

Mingw-w64 has official release. All bigger distributors have done already a lot of different releases for it. Just for the interest people, mingw-w64 already has 3 different release-branches. Current release-version we provide is 3.4. So, this is for sure no valid point. We have official releases, and we had actually already more then one ...

What libraries "mingw-w64" breaks often?!? Could you please go in detail? I am curious to hear that, as all distributors I know (Fedora, Debian, OpenSuse, ArchLinux, ...) haven't reported this. Or is that just one thing you have a "gut" feeling about?

> And no, MinGW64 is not a superset of MinGW32, it's a different
> project with an incompatible ABI and subtly incompatible header files.
> (Please don't start an argument about that, I'm not really
> interested.)

True, MinGW.org and mingw-w64 are two different ventures with differences in feature-sets. Actually, mingw-w64 supports most (if not all) what MinGW.org supports plus a bit more (Unicode-entry support, 64-bit and 32-bit, partial ARM 32 support, supporting also other compilers then just gcc (but of course gcc is our main-target, full C99-math, working complex-math support, etc).

Just one point here I got curious about. What you mean by ABI? The ABI of mingw-targets is the same for all targets using gcc. So what ABI-differences you are talking about?!?

> Even if there were no problems with MinGW64, I don't think we should
> stop supporting MinGW32 just like that, it is still a live project,
> and I, for one, is quite happy with it. I hope GDB will not drop its
> support any time soon.

No problem about this, but why blocking things not related to MinGW.org?

Kai