From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14721 invoked by alias); 18 Dec 2014 20:55:03 -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 14712 invoked by uid 89); 18 Dec 2014 20:55:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f53.google.com Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 18 Dec 2014 20:55:01 +0000 Received: by mail-wg0-f53.google.com with SMTP id l18so2674545wgh.40 for ; Thu, 18 Dec 2014 12:54:58 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.85.34 with SMTP id e2mr14390830wiz.0.1418936098574; Thu, 18 Dec 2014 12:54:58 -0800 (PST) Received: by 10.27.201.214 with HTTP; Thu, 18 Dec 2014 12:54:58 -0800 (PST) In-Reply-To: <83k31ou1mi.fsf@gnu.org> References: <20141217210144.GA26674@host2.jankratochvil.net> <83wq5oub28.fsf@gnu.org> <20141218173103.GA18871@host2.jankratochvil.net> <83sigcua9l.fsf@gnu.org> <526566540.670835.1418933688966.JavaMail.zimbra@redhat.com> <83k31ou1mi.fsf@gnu.org> Date: Thu, 18 Dec 2014 20:55:00 -0000 Message-ID: Subject: Re: [patch] compile: rm -rf -> ftw()+rmdir()+unlink() [Re: [patch] compile: Fix MinGW build] From: Kai Tietz To: Eli Zaretskii Cc: Kai Tietz , Jan Kratochvil , sellcey@imgtec.com, Joel Brobecker , Yao Qi , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00550.txt.bz2 2014-12-18 21:47 GMT+01:00 Eli Zaretskii : >> Date: Thu, 18 Dec 2014 15:14:48 -0500 (EST) >> From: Kai Tietz >> Cc: Jan Kratochvil , 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 sup= erset >> > > >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? > > I don't see it as a problem, necessarily. > >> The mingw-w64 target support ftw, so why not simply allow it for targets= providing it, and other targets can be covered by gnulib? > > Sure, why not? I wasn't objecting to that, I just provided > information, since Jan seemed to think ftw is available everywhere. > >> What libraries "mingw-w64" breaks often?!? Could you please go in detai= l? 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? > > The latest that I saw is this: > > http://lists.gnu.org/archive/html/bug-gnulib/2014-12/msg00186.html > > And I remember a few more lately. Hmm, this isn't something we got reported at all. As you are using pthread-library based toolchain (this is a build-option, and not a mandatory mingw-w64 thing at all) I don't see that this is a mingw-w64 venture issue at all. Btw we (on mingw-w64) strongly recomment to use winpthread instead, as it solves some quirks existing with other pthread-implementations available for Win32 ... anyway later is off-topic. > But look, I don't want to argue, I specifically said that. Jan asked > why not forget about MinGW32, and I gave _my_ reasons. You don't have > to agree, and we don't have to convince each other. My only request > is that GDB doesn't drop MinGW32 support. Sure, no problem about that. Nevertheless I have a problem if you try to tell people things not true. >> 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-differ= ences you are talking about?!? > > Exception handling across DLLs is one difference I know of. This is again a build-option of gcc, and has nothing directly to do with mingw-w64. For example, you can find for 32-bit dw2 based exception-handling toolchain provided by mingw-builds projects (and some others providing for 32-bit dw2 too). For 64-bit there is SEH, which replaces dw2 completely. >> > 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? > > I didn't, it's a misunderstanding. Sorry if I caused it. Ok, np. Kai