This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [MinGW-w64]Build gdb/ctf.c failed
- From: Kai Tietz <ktietz70 at googlemail dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: asmwarrior at gmail dot com, tromey at redhat dot com, yao at codesourcery dot com, gdb-patches at sourceware dot org
- Date: Mon, 25 Mar 2013 14:30:15 +0100
- Subject: Re: [MinGW-w64]Build gdb/ctf.c failed
- References: <83ip4s4ixc dot fsf at gnu dot org> <1363407692-18959-1-git-send-email-yao at codesourcery dot com> <1363407692-18959-4-git-send-email-yao at codesourcery dot com> <CADPb22RwSq0iv_gQu5PSGezQoUy0ve16M2hmL51HvM19v0M5Ow at mail dot gmail dot com> <51492077 dot 30307 at codesourcery dot com> <83sj3qyogk dot fsf at gnu dot org> <87vc8m7z1d dot fsf at fleche dot redhat dot com> <514FA117 dot 9030604 at gmail dot com> <83hajz3oef dot fsf at gnu dot org> <CAEwic4Y020-LqwtNeYFXn3oQvk5fWBFm1T5ZoAmwqPSpD=PASg at mail dot gmail dot com> <83boa73mty dot fsf at gnu dot org> <CAEwic4aP6EHo0Kxu=qxCF1MFNWPt02QoSAUyuRuN1riAJif8Yg at mail dot gmail dot com> <837gkv3maf dot fsf at gnu dot org> <CAEwic4ag2-dHuoZHwLApVdoYzb+ueP1+xV+sBa0NOnpB+s4NOg at mail dot gmail dot com> <8338vj3i1w dot fsf at gnu dot org> <CAEwic4Z0kRjmUuEh3y5h6uMCCSyzxwScGwzspD2jwxP1xYx3rA at mail dot gmail dot com> <83wqsv1v4b dot fsf at gnu dot org>
2013/3/25 Eli Zaretskii <eliz@gnu.org>:
>> Date: Mon, 25 Mar 2013 13:42:52 +0100
>> From: Kai Tietz <ktietz70@googlemail.com>
>> 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.
Well, our sys/stat.h header depends on io.h and by this it gets also
the mkdir prototype. From our POV this is the proper thing to do
here.
>> 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.
Right, and it isn't something POSIX requests. So well, we could
prototype it in io.h header, too. But well, I can put apple-juice
into a milk-bottle, and technical it is ok, but logical people
wouldn't expect it there. It is an MS extension, so include proper
header for it ...
>> 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.
And here is the confusion. See aboive that _mkdir is an MS extension
and you shouldn't expect that declared as side-effect. Actual that
you get it by mingw.org's unistd.h is an implementation detail you
should never rely on.
>> 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:
Well, we are pretty aware about that, but it doesn't make it more
reasonable why _mkdir should be declared by unistd.h header (or io.h
header). Actual mingw-w64 even provides a feature to warn about his
deprecated API, if you are eager to see that.
> 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.
Yeah, that is something created by history ... I admit that unistd.h
should better do actual the define for mkdir ... not sure how many
ventures might get affected for their Windows port here. Additional a
define has the disadvantage of not providing proper function-point
feature, but a static function in header might cause other issues ...
>> 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.
Yeah, and that's an implementation detail and IMHO even a bug, because
msdn is documenting it differently ... but well that is in this case
just nit-picking.
> 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
Yeah, therefore don't rely on implementation details.
> http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00611.html
Yeah, saw that too.