Message ID | 74ea0c62ebe19db186263053e4051f81d46e9da4.camel@xry111.site |
---|---|
Headers | show |
Series | Stop using obsoleted egrep/fgrep | expand |
Hi Xi, > egrep and fgrep have been deprecated for a long time, and the next grep > release will emit a warning if egrep or fgrep is invoked: > > https://git.savannah.gnu.org/cgit/grep.git/commit/?id=a951562 > > To prevent us from a lot of these warnings in the future, we should stop > using egrep and fgrep. These patches will remove most of the use of > egrep or fgrep from GCC building system. The remaining: please remember that there's a world outside of GNU grep: e.g. Solaris /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so unconditionally replacing egrep with grep -E in several places is likely to break at least the Solaris build. Please see the autoconf manual for details. I suspect you'll have to rework the patch set to use AC_PROG_EGREP and $EGREP instead. Rainer
On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote: > please remember that there's a world outside of GNU grep: e.g. Solaris > /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so > unconditionally replacing egrep with grep -E in several places is > likely > to break at least the Solaris build. > > Please see the autoconf manual for details. I suspect you'll have to > rework the patch set to use AC_PROG_EGREP and $EGREP instead. Thanks for the advice. I'll rework on it. Is there some way to access a Solaris and do some test?
Hi Xi, > On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote: > >> please remember that there's a world outside of GNU grep: e.g. Solaris >> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so >> unconditionally replacing egrep with grep -E in several places is >> likely >> to break at least the Solaris build. >> >> Please see the autoconf manual for details. I suspect you'll have to >> rework the patch set to use AC_PROG_EGREP and $EGREP instead. > > Thanks for the advice. I'll rework on it. > > Is there some way to access a Solaris and do some test? Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile farm (https://gcc.gnu.org/wiki/CompileFarm). Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the moment, but those don't differ in this regard. Rainer
On 2022-06-24, Rainer Orth wrote: >Hi Xi, > >> On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote: >> >>> please remember that there's a world outside of GNU grep: e.g. Solaris >>> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so >>> unconditionally replacing egrep with grep -E in several places is >>> likely >>> to break at least the Solaris build. >>> >>> Please see the autoconf manual for details. I suspect you'll have to >>> rework the patch set to use AC_PROG_EGREP and $EGREP instead. >> >> Thanks for the advice. I'll rework on it. >> >> Is there some way to access a Solaris and do some test? > >Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile >farm (https://gcc.gnu.org/wiki/CompileFarm). > >Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the >moment, but those don't differ in this regard. > > Rainer FWIW: glibc recently got the grep -E change and the solution is to use plain grep -E, without $EGREP things. Isn't setting PATH a good workaround if Solaris has the problem? https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html > Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only > vendor-supported platform I know of where '/usr/bin/grep -E' does not > work is Solaris 10 (end-of-life January 2024), and that's easily fixed > by prepending /usr/xpg4/bin to PATH.
On Fri, Jun 24, 2022 at 1:27 AM Fangrui Song via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > On 2022-06-24, Rainer Orth wrote: > >Hi Xi, > > > >> On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote: > >> > >>> please remember that there's a world outside of GNU grep: e.g. Solaris > >>> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so > >>> unconditionally replacing egrep with grep -E in several places is > >>> likely > >>> to break at least the Solaris build. > >>> > >>> Please see the autoconf manual for details. I suspect you'll have to > >>> rework the patch set to use AC_PROG_EGREP and $EGREP instead. > >> > >> Thanks for the advice. I'll rework on it. > >> > >> Is there some way to access a Solaris and do some test? > > > >Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile > >farm (https://gcc.gnu.org/wiki/CompileFarm). > > > >Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the > >moment, but those don't differ in this regard. > > > > Rainer > > FWIW: glibc recently got the grep -E change and the solution is to use > plain grep -E, without $EGREP things. > Isn't setting PATH a good workaround if Solaris has the problem? glibc is a different story partly but I think GCC should go down the EGREP route. glibc is not as friendly to non-GNU based systems compared to GCC really. Though I do find that -E/-F have been part of the POSIX standard since at least 2004 which is interesting. https://pubs.opengroup.org/onlinepubs/009696899/utilities/grep.html Though GCC host/build targets can be older and some non-supported ones still. Thanks, Andrew Pinski > > https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html > > > Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only > > vendor-supported platform I know of where '/usr/bin/grep -E' does not > > work is Solaris 10 (end-of-life January 2024), and that's easily fixed > > by prepending /usr/xpg4/bin to PATH.
Hi Fangrui, > FWIW: glibc recently got the grep -E change and the solution is to use > plain grep -E, without $EGREP things. > Isn't setting PATH a good workaround if Solaris has the problem? > > https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html while it's possible, the $PATH solution is fragile and I fear the errors that one gets all over the place when it's missed are highly unintuitive and hard to diagnose. >> Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only >> vendor-supported platform I know of where '/usr/bin/grep -E' does not >> work is Solaris 10 (end-of-life January 2024), and that's easily fixed by >> prepending /usr/xpg4/bin to PATH. I'm not concerned about Solaris 10 at all: it's no longer supported by GCC and GDB and while binutils formally still does, there's not much value in having current binutils with older gcc etc. Rainer
On Fri, 24 Jun 2022, Andrew Pinski via Gcc-patches wrote: > Though I do find that -E/-F have been part of the POSIX standard since > at least 2004 which is interesting. grep -E and -F are already defined, and egrep and fgrep marked as obsolescent, in the 1992/1993 edition of POSIX.2.
> On 24 Jun 2022, at 17:09, Joseph Myers <joseph@codesourcery.com> wrote: > > On Fri, 24 Jun 2022, Andrew Pinski via Gcc-patches wrote: > >> Though I do find that -E/-F have been part of the POSIX standard since >> at least 2004 which is interesting. > > grep -E and -F are already defined, and egrep and fgrep marked as > obsolescent, in the 1992/1993 edition of POSIX.2. FWIW, grep -E/F is supported by the oldest Darwin versions I care about so, I have no objections to these changes. Iain