From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18420 invoked by alias); 25 Mar 2013 13:12:48 -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 17939 invoked by uid 89); 25 Mar 2013 13:12:37 -0000 X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.1 Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 25 Mar 2013 13:12:33 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MK700500WGL4N00@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Mon, 25 Mar 2013 15:12:10 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MK7005TJWOA1450@a-mtaout21.012.net.il>; Mon, 25 Mar 2013 15:12:10 +0200 (IST) Date: Mon, 25 Mar 2013 15:44:00 -0000 From: Eli Zaretskii Subject: Re: [MinGW-w64]Build gdb/ctf.c failed In-reply-to: To: Kai Tietz Cc: asmwarrior@gmail.com, tromey@redhat.com, yao@codesourcery.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83wqsv1v4b.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> X-SW-Source: 2013-03/txt/msg00930.txt.bz2 > Date: Mon, 25 Mar 2013 13:42:52 +0100 > From: Kai Tietz > Cc: asmwarrior@gmail.com, tromey@redhat.com, yao@codesourcery.com, > gdb-patches@sourceware.org > > So, you claimed MinGW-w64 did something wrong ... well, if we wouldn't > declare mkdir here, indeed it would be worth a bug-report ... Actually, Posix says mkdir should be in sys/stat.h, not in unistd.h. And it looks like MinGW64 does indeed have mkdir in stat.h, not in unistd.h. Which IMO is another unfortunate incompatibility with mingw.org. > So what differences you were talking about? The difference that caused the warning -- the fact that _mkdir's prototype was not visible after including unistd.h. > 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. Yes (but see below about its Posix nature). > So you mean yet _mkdir? Yes, of course. _mkdir was the reason for the compiler warning. If it were declared in io.h, then the warning would not have been emitted. > 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. Unfortunately, this isn't so simple, as MS API offers mkdir as well (see direct.h in any MS SDK), albeit while discouraging/deprecating its use: http://msdn.microsoft.com/en-us/library/vstudio/ms235326%28v=vs.100%29.aspx Thus, mkdir is both a Posix API and an MS API. Moreover, the Posix mkdir accepts 2 arguments, not one. So what MinGW provides is not really a Posix API, but rather a slightly incompatible variant thereof. > 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. MinGW's unistd.h includes io.h, and thus gets both mkdir and _mkdir. One could perhaps argue that this is or isn't a mistake, but given the precedence, having a different arrangement in MinGW64 is unfortunate, since it will mean more #ifdef'ing in the projects that want to support both. For yet another example of such incompatibilities, see http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00611.html