Re: [PATCH 2/2] Windows libcpp: Make path-exists semantics more Posix-like

[Ray Donnelly <mingw.android@gmail.com>]

On Fri, Apr 25, 2014 at 9:33 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2014-04-25 21:24 GMT+02:00 Pedro Alves <palves@redhat.com>:
>> On 04/25/2014 08:05 PM, Kai Tietz wrote:
>>> 2014-04-25 18:53 GMT+02:00 Pedro Alves <palves@redhat.com>:
>>>> On 04/19/2014 09:41 PM, Kai Tietz wrote:
>>>>
>>>>> Isn't this function something better placed in libiberty?  Also this name looks a bit confusing.  Wouldn't be a an function calling for _WIN32 case also stat, and just overrides the st_mode member, if it is a link better.  So I would put this function to the file_... API of libiberty.
>>>>
>>>> I'd even suspect that e.g., GNU Make / Makefiles would be likewise affected
>>>> by this.  A solution for this in gcc, or in a few selected programs
>>>> only, looks brittle to me.  Perhaps it should be mingw itself that provides
>>>> a _non-default_ replacement as option (similarly to __mingw_printf).
>>>
>>> Of course we could change default-behavior of stat-function within
>>> mingw.
>>
>> Huh?  I said exactly the opposite.  To expose it as a __non-default__
>> replacement.  I pointed at __mingw_printf, so to suggest programs
>> would call it like __mingw_stat or something, or by defining
>> __USE_MINGW_POSIX_STAT or something, just like one can define
>> __USE_MINGW_ANSI_STDIO before including stdio.h.  I'll understand
>> if you wouldn't want to support that as an option, but I did _not_
>> suggest making it the default.
>
> As none-default replacement it makes even less sense in mingw IMO.
> the __mingw_printf (and related functions) are there for providing C99
> functionality.  What standard shall __mingw_stat satisfy?
>
>>> I think that libiberty is exactly present to unify functionality (and
>>> API) for different operation systems.  Exactly for this libiberty was
>>> made, isn't it?
>>
>> libiberty is actually a kitchen sink, and specific to gcc and src.
> Well it is shared with binutils.  And in the past gdb used it too (I
> think it still does in some way, as not everything is in glib.  I
> might be wrong about this).
>
>> It does more than host abstraction.  Gnulib fills that role much better
>> nowdays.  I'd be nice if gcc used that instead for the host abstraction
>> parts (gdb does), but nobody's working on that afaik...
>
> That's true for gdb.  I don't see that binutils or gcc use glib.  So I
> can only talk in this thread about what gcc/binutils uses right now.
> Actually I am not really interested in what kind of compatibility
> library is used.
> Nevertheless to hi-jack this thread to start a discussion about
> preferring glib over other (already existing) library in gcc/binutils
> isn't ok.  Please start for such a discussion a separate RFC-thread.
>
>>> I agree that there are other venture, which might be affected by same
>>> problem.  So those venture could either use libiberty to solve this
>>> problem too, or need to reimplement it as they do now.
>>
>> And then we'll have reinvented Cygwin all over the map.  ;-)
>
> Huh?  mingw != cygwin.  and mingw's internal libraries aren't a
> kitchen-sink too.
>
>>>> Can't glibc be changed to not rely on this?  /me hides.

Yes mingw != cygwin, but we'd still like to be able to cross compile
glibc on Windows targeting GNU/Linux and this patch is necessary for
that to work. I see benefits in normalizing the behavior over three
build machine OSes (GNU/Linux, OS X and WIndows) and for all projects
being built (rather than just changing glibc). If I hear any positive
noises, I'll send a re-based version of the patch.

--
Ray

>>
>> --
>> Pedro Alves
>
> ---
> Kai Tietz