From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47809 invoked by alias); 18 Aug 2015 20:15:51 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 47800 invoked by uid 89); 18 Aug 2015 20:15:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f174.google.com Received: from mail-lb0-f174.google.com (HELO mail-lb0-f174.google.com) (209.85.217.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 18 Aug 2015 20:15:49 +0000 Received: by lbbsx3 with SMTP id sx3so110563598lbb.0 for ; Tue, 18 Aug 2015 13:15:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.116.109 with SMTP id jv13mr8089634lab.77.1439928946092; Tue, 18 Aug 2015 13:15:46 -0700 (PDT) Received: by 10.112.42.234 with HTTP; Tue, 18 Aug 2015 13:15:45 -0700 (PDT) In-Reply-To: References: <1397936424-2290-1-git-send-email-mingw.android@gmail.com> <1397936424-2290-3-git-send-email-mingw.android@gmail.com> <1034557352.9542218.1397940098399.JavaMail.zimbra@redhat.com> <535A92FD.5080009@redhat.com> <535AB650.1080102@redhat.com> Date: Tue, 18 Aug 2015 20:23:00 -0000 Message-ID: Subject: Re: [PATCH 2/2] Windows libcpp: Make path-exists semantics more Posix-like From: Ray Donnelly To: Kai Tietz Cc: Pedro Alves , Kai Tietz , GCC Patches , Kai Tietz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-08/txt/msg01029.txt.bz2 On Fri, Apr 25, 2014 at 9:33 PM, Kai Tietz wrote: > 2014-04-25 21:24 GMT+02:00 Pedro Alves : >> On 04/25/2014 08:05 PM, Kai Tietz wrote: >>> 2014-04-25 18:53 GMT+02:00 Pedro Alves : >>>> 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 c= ase also stat, and just overrides the st_mode member, if it is a link bette= r. 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 aff= ected >>>> 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 pro= vides >>>> 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 !=3D 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 !=3D 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