On Fri, Apr 25, 2014 at 9:33 PM, Kai Tietz <ktiet...@googlemail.com> wrote: > 2014-04-25 21:24 GMT+02:00 Pedro Alves <pal...@redhat.com>: >> On 04/25/2014 08:05 PM, Kai Tietz wrote: >>> 2014-04-25 18:53 GMT+02:00 Pedro Alves <pal...@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
