From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20007 invoked by alias); 18 Dec 2014 20:15:06 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 19993 invoked by uid 89); 18 Dec 2014 20:15:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx4-phx2.redhat.com Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 18 Dec 2014 20:15:03 +0000 Received: from zmail14.collab.prod.int.phx2.redhat.com (zmail14.collab.prod.int.phx2.redhat.com [10.5.83.16]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id sBIKEnAf007478; Thu, 18 Dec 2014 15:14:50 -0500 Date: Thu, 18 Dec 2014 20:15:00 -0000 From: Kai Tietz To: Eli Zaretskii Cc: Jan Kratochvil , sellcey@imgtec.com, brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org Message-ID: <526566540.670835.1418933688966.JavaMail.zimbra@redhat.com> In-Reply-To: <83sigcua9l.fsf@gnu.org> References: <20141217210144.GA26674@host2.jankratochvil.net> <83wq5oub28.fsf@gnu.org> <20141218173103.GA18871@host2.jankratochvil.net> <83sigcua9l.fsf@gnu.org> Subject: Re: [patch] compile: rm -rf -> ftw()+rmdir()+unlink() [Re: [patch] compile: Fix MinGW build] MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-12/txt/msg00547.txt.bz2 ----- Urspr=C3=BCngliche Mail ----- > > Date: Thu, 18 Dec 2014 18:31:03 +0100 > > From: Jan Kratochvil > > Cc: ktietz@redhat.com, sellcey@imgtec.com, brobecker@adacore.com, > > yao@codesourcery.com, gdb-patches@sourceware.org > >=20 > > >From the Fedora point of view MinGW64 32-bit mode seems to be a supers= et > > >of > > MinGW32 so why to care about MinGW32 anymore? Or what do I miss? >=20 > 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. =20 > 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-w6= 4 already has 3 different release-branches. Current release-version we pro= vide is 3.4. So, this is for sure no valid point. We have official releas= es, 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, Op= enSuse, ArchLinux, ...) haven't reported this. Or is that just one thing y= ou 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 i= n 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, par= tial 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-differenc= es 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