From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25112 invoked by alias); 25 Mar 2013 12:43:04 -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 25084 invoked by uid 89); 25 Mar 2013 12:42:57 -0000 X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,FREEMAIL_REPLY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 Received: from mail-ie0-f182.google.com (HELO mail-ie0-f182.google.com) (209.85.223.182) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 25 Mar 2013 12:42:54 +0000 Received: by mail-ie0-f182.google.com with SMTP id at1so3304806iec.41 for ; Mon, 25 Mar 2013 05:42:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.196.165 with SMTP id in5mr11036065igc.99.1364215372943; Mon, 25 Mar 2013 05:42:52 -0700 (PDT) Received: by 10.64.14.129 with HTTP; Mon, 25 Mar 2013 05:42:52 -0700 (PDT) In-Reply-To: <8338vj3i1w.fsf@gnu.org> References: <83ip4s4ixc.fsf@gnu.org> <1363407692-18959-1-git-send-email-yao@codesourcery.com> <1363407692-18959-4-git-send-email-yao@codesourcery.com> <51492077.30307@codesourcery.com> <83sj3qyogk.fsf@gnu.org> <87vc8m7z1d.fsf@fleche.redhat.com> <514FA117.9030604@gmail.com> <83hajz3oef.fsf@gnu.org> <83boa73mty.fsf@gnu.org> <837gkv3maf.fsf@gnu.org> <8338vj3i1w.fsf@gnu.org> Date: Mon, 25 Mar 2013 15:18:00 -0000 Message-ID: Subject: Re: [MinGW-w64]Build gdb/ctf.c failed From: Kai Tietz To: Eli Zaretskii Cc: asmwarrior@gmail.com, tromey@redhat.com, yao@codesourcery.com, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-03/txt/msg00929.txt.bz2 2013/3/25 Eli Zaretskii : >> Date: Mon, 25 Mar 2013 10:15:14 +0100 >> From: Kai Tietz >> Cc: asmwarrior@gmail.com, tromey@redhat.com, yao@codesourcery.com, >> gdb-patches@sourceware.org >> >> >> You are driveling ... >> > >> > Very mature. Thanks a lot. >> >> Be welcome. > > I'm not, actually. > >> Sorry, but I want to insist on such apparent things. I am wondering >> about your arguments, due you should know better. > > I have no idea what I "should know better". If you wonder about my > arguments, you can always ask for clarifications. We are both > writing in a language that isn't our first one, so misunderstanding is > much more probable than anything else. Well, some of this might be caused by foreign tongue. What I meant by ... well let me say confused instead of "drivel" ... its English meaning is more harsh as I wanted to say: First cite of your reply within that thread I want to reference is: "Is mkdir declared in MinGW64 unistd.h? If so, can you please show its declaration from unistd.h? Also, what other headers are included in MinGW64 unistd.h? I dislike using Windows-specific headers in general source files. MinGW unistd.h (which is absent from MS SDK's) was created for that very purpose. If MinGW64 is breaking that, IMO it's a MinGW64 bug that needs to be reported to them, while we look for the cleanest way of fixing this annoyance." So, you claimed MinGW-w64 did something wrong ... well, if we wouldn't declare mkdir here, indeed it would be worth a bug-report ... And then you ware asking the following question to Asmwarrior: "Isn't _mkdir also declared in io.h?" Well, so I assume that you are meaning _mkdir in first offensive cite, as this function was actual used by Yao Qi's patch. After you got the reply by Yao Qi you wrote: "Too bad. Gratuitous differences between the different MinGW variants are likely to become maintenance headaches in the long run. Like in this case." So what differences you were talking about? The function mkdir is declared for MinGW.org, and for MinGW-w64. It is the POSIX compliant API name and both ventures are declaring it in an POSIX-helper header. So you mean yet _mkdir? The few mingw posix extensions are there in order to make porting a bit easier. if you want to use a posix function, include the corresponding posix header; if you want to a MS API, use the header MS defines the function/interface lives in. it wouldn't really help portability (in either direction) to support including a posix header, and getting a MS API function, so mingw doesn't lay its headers that way. The header io.h isn't a POSIX one, and therefore you should just expect what actual is documented by vendor (in msdn) for it and not what one implementation mightz does. Kai