This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] compile: rm -rf -> ftw()+rmdir()+unlink() [Re: [patch] compile: Fix MinGW build]
- From: Kai Tietz <ktietz at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, sellcey at imgtec dot com, brobecker at adacore dot com, yao at codesourcery dot com, gdb-patches at sourceware dot org
- Date: Thu, 18 Dec 2014 15:14:48 -0500 (EST)
- Subject: Re: [patch] compile: rm -rf -> ftw()+rmdir()+unlink() [Re: [patch] compile: Fix MinGW build]
- Authentication-results: sourceware.org; auth=none
- References: <20141217210144 dot GA26674 at host2 dot jankratochvil dot net> <83wq5oub28 dot fsf at gnu dot org> <20141218173103 dot GA18871 at host2 dot jankratochvil dot net> <83sigcua9l dot fsf at gnu dot org>
----- 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