[Bug libgcj/37019] New: [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[Bug libgcj/37019] New: [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rob1weld at aol dot com]

The gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and
"$EGGREP" (but not "ggrep") in a non-portable and inconsistent manner.

Examples:

1. Lines 5224, 5254, 5295, 5298, etc...  use "egrep" but "EGREP" is not tested
for (to decide if we will use "grep -E" or "egrep") until line 7315 and not set
until line 7322.

Correct usage would be to check if we need to use "ggrep" since on Solaris
"grep" is NOT the GNU grep, instead "ggrep" is the GNU grep. A few simple
commands in Solaris's "grep" _are_ compatable with GNU's "grep" but most
commands are not.

Solaris also has "egrep" and "fgrep" but those are also both Non-GNU programs.

To use "egrep" or "fgrep" (in Solaris) you must use "ggrep -E" or "ggrep -F".

---

The other problem is that Solaris (I have the newest version) does not have a
GNU sed program. Worse news. It _does_ have a "sed" program, but there is no
command to obtain a version number. Looking at the "man sed" command says that
the man page is dated "23 Jul 1998". In a "normal" installation of Solaris
there is no "gsed" command.

The GNU "sed" command can be tested by running "sed --version" and it will
reply "GNU sed version x.y.z". The Solaris "sed" command has no means to check
it's version (that I am aware of -- you might ggrep the binary ;) ).


If someone wants a "gsed" command for Solaris they must either compile "sed"
themselves or type this (see this URL: http://www.blastwave.org/howto.html):

# pkgadd -d http://www.blastwave.org/pkg_get.pkg
# /opt/csw/bin/pkg-get -U 
# /opt/csw/bin/pkg-get -i wget
# /opt/csw/bin/pkg-get -i gsed

That provides a "GNU sed" as "/opt/csw/bin/gsed". It is version 4.1.4

Elsewhere in gcc I have noticed that other configure scripts do not have this
problem, they do check for the "g"-prefixed commands. The (correct) configury
uses tests to set environment variables that are used for the program's name
throughout the rest of the script.


-- 
           Summary: [4.2 Regression] Inconsistent gcc-
                    4.2.3/libjava/configure uses "grep" and "egrep" and
                    "grep -E" and "$EGGREP"  but not ggrep -- sed also is
                    trouble
           Product: gcc
           Version: 4.2.3
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rob1weld at aol dot com
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rwild at gcc dot gnu dot org]

------- Comment #1 from rwild at gcc dot gnu dot org  2008-08-04 08:57 -------
I see the egrep issue.

Can you please specify for which grep and sed commands you see errors?

The assumption is that all systems do have sed and grep available, but
that the vendor versions of these tools have some quirks that make it
unsuitable for some (but not all) uses.  Wrt. egrep and fgrep, there
are systems for which 'grep -E' and 'grep -F' have to be used.

If any of these assumptions are not valid, then I would like to know
details, so that the Autoconf manual can be updated to reflect this.


-- 

rwild at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rwild at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rob1weld at aol dot com]

------- Comment #2 from rob1weld at aol dot com  2008-08-04 17:18 -------
>Ralf Wildenhues  2008-08-04 08:57 wrote:
>I see the egrep issue.

Would you click the "CONFIRMED" button please.


> Can you please specify for which grep and sed commands you see errors?

I need to build some dependencies (that will take a few days) before I can run
the _entire_ script, but I do have an initial report (see below) ...


> The assumption is that all systems do have sed and grep available, but
> that the vendor versions of these tools have some quirks that make it
> unsuitable for some (but not all) uses.  Wrt. egrep and fgrep, there
> are systems for which 'grep -E' and 'grep -F' have to be used.

> If any of these assumptions are not valid, then I would like to know
> details, so that the Autoconf manual can be updated to reflect this.


> > If any of these assumptions are not valid ...
> > have some quirks that make it unsuitable for some (but not all) uses

Assume that _ALL_ commands (grep, make, egrep, diff, _everything_) are not
"valid" _GNU_ commands. 

The creator of the Operating System can name any command any name they want
(EG: Ralph can be spelled Ralf or Rolf etc). Similarly grep can be called sed
and sed can be called diff -- I'm not suggested that is a good idea, just that
it is possible.


>From a practical point of view it makes sense to run the command with
"--version" (or "-v" or "-V") and check that it is indeed a GNU program and
that the version is "new enough" that _ALL_ following uses of the command will
operate correctly.

Yes, that would be a rewrite of a lot of scripts but if you want to make sure
that everything works you need the sanity tests to run at the beginning of each
script. If you don't check that you are sane then how can you decide anything ?

---

The Solaris 11 OS that I am using is only a couple of months old.

When I do a directory listing to find my "g-prefixed" commands I get a list
like this (I edited out some obvious commands that are not "g-prefixed"
versions and hopefully was not too heavy-handed):

# ls -l /usr/bin/g*
-r-xr-xr-x   1 root     bin        30432 Jun 26 18:26 /usr/bin/gcmp
...
-r-xr-xr-x   1 root     bin       151740 Jun 26 18:26 /usr/bin/gdiff
-r-xr-xr-x   1 root     bin        36712 Jun 26 18:26 /usr/bin/gdiff3
...
-r-xr-xr-x   3 root     bin       116268 Jun 26 17:02 /usr/bin/gegrep
...
-r-xr-xr-x   3 root     bin       116268 Jun 26 17:02 /usr/bin/gfgrep
-r-xr-xr-x   1 root     bin        23568 Jun 26 19:58 /usr/bin/ggettext
-r-xr-xr-x   3 root     bin       116268 Jun 26 17:02 /usr/bin/ggrep
...
-r-xr-xr-x   1 root     bin       151780 Jun 26 18:00 /usr/bin/gm4
-r-xr-xr-x   1 root     bin       153036 Jun 26 18:01 /usr/bin/gmake
...
-r-xr-xr-x   1 root     bin       315084 Jun 26 19:58 /usr/bin/gmsgfmt
...
-r-xr-xr-x   1 root     bin        88376 Jun 26 16:48 /usr/bin/gpatch
...
-r-xr-xr-x   1 root     bin        34728 Jun 26 18:26 /usr/bin/gsdiff
...
-r-xr-xr-x   1 root     bin       312884 Jun 26 17:02 /usr/bin/gtar


That is about all I can spot from eye / memory / knowledge about GNUisms.


That list is, again: gcmp, gdiff, gdiff3, gegrep, gfgrep, ggettext, ggrep, gm4,
gmake, gmsgfmt, gpatch, gsdiff, gtar, (etc, possibly I missed one).

This means that any attempt to use these programs (on Solaris and _some_ other
OSes) will fail.


Here is the output for each program and for Solaris 11's "g-prefixed" version:

---
# cmp --version
cmp: illegal option -- version
usage: cmp [-l | -s] file1 file2 [skip1] [skip2]

# gcmp --version
cmp (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Written by Torbjorn Granlund and David MacKenzie.
---
# diff --version
diff: illegal option -- version
usage: diff [-bitw] [-c | -e | -f | -h | -n | -u] file1 file2
       diff [-bitw] [-C number | -U number] file1 file2
       diff [-bitw] [-D string] file1 file2
       diff [-bitw] [-c | -e | -f | -h | -n | -u] [-l] [-r] [-s] [-S name]
directory1 directory2

# gdiff --version
diff (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Written by Paul Eggert, Mike Haertel, David Hayes,
Richard Stallman, and Len Tower.
---
# diff3 --version
usage: diff3 file1 file2 file3

# gdiff3 --version
diff3 (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Written by Randy Smith.
---
# egrep --version
egrep: illegal option -- version
usage: egrep [ -bchilnsv ] [ -e exp ] [ -f file ] [ strings ] [ file ] ...
# gegrep --version
egrep (GNU grep) 2.5

Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---
# fgrep --version
fgrep: illegal option -- version
usage: fgrep [ -bchilnsvx ] [ -e exp ] [ -f file ] [ strings ] [ file ] ...
# gfgrep --version
fgrep (GNU grep) 2.5

Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---
(NOTE: Solaris's "gettext" echos the "--version" _without_ a C/R)
---
# gettext --version
--version# ggettext --version
ggettext (GNU gettext-runtime) 0.16.1
Copyright (C) 1995-1997, 2000-2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Ulrich Drepper.
---
# grep --version
grep: illegal option -- version
Usage: grep -hblcnsviw pattern file . . .
# ggrep --version
grep (GNU grep) 2.5

Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---
# m4 --version
m4: bad option: --version
# gm4 --version

GNU m4 1.4.2
---
# make --version
make: Warning: Ignoring DistributedMake -v option
make: Warning: Ignoring DistributedMake -o option
make: Fatal error: No dmake output dir argument after -o flag
# gmake --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-pc-solaris2.11
---
# msgfmt --version
ERROR: Cannot open file --version.
# gmsgfmt --version
gmsgfmt (GNU gettext-tools) 0.16.1
Copyright (C) 1995-1998, 2000-2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Ulrich Drepper.
---
# patch --version
patch: Invalid options.
patch: Usage:   patch [-blNR] [-c|-e|-n] [-d dir] [-D define] [-i patchfile]\
              [-o outfile] [-p num] [-r rejectfile] [file]
# gpatch --version
patch 2.5.9
Copyright (C) 1988 Larry Wall
Copyright (C) 2003 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall and Paul Eggert
---
# sdiff --version
Usage: sdiff [-l] [-s] [-o output] [-w #] file1 file2
# gsdiff --version
sdiff (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Written by Thomas Lord.
---
# tar --version
tar: s: unknown function modifier
Usage: tar {c|r|t|u|x}[BDeEFhilmnopPqTvw@/[0-7]][bfk][X...] [blocksize]
[tarfile] [size] [exclude-file...] {file | -I include-file | -C directory
file}...
# gtar --version
tar (GNU tar) 1.17
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
---

--------------------


To answer your question "Can you please specify for which grep and sed commands
you see errors?" here is an attempt to comply (until I finish the dependencies
(_if_ they can be built on this platform)) I can't finsh running the script
(and will have to remove the "qt" options I am configuring with).


Here is a comparison of the i386-pc-solaris2.11/libjava/config.log files with
the origonal "configure" and my modified "configure" where I added "g-prefixes"
everywhere I could see it was necessary. To shorten the list I edited the
output by hand:

# gdiff -Naur config_Origonal_configure.log config_Modified-1_configure.log
(Enclosed as an attachment in next message)

You can see how serious this is. The configury is getting a one-off error in
uname, doesn't know the "Invocation command line", reads the wrong specs file,
checks "gcc -v" instead of "xgcc -v", the list goes on and on ...

Basically the first few mistakes compound the rest and even _IF_ a later grep
command _could_ work (command is compatable with both (Solaris) grep and (GNU)
ggrep) it has little chance if it is fed incorrect information.


(See attachment in next message).

Thanks for looking at this Ralf.

YT,
Rob


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rob1weld at aol dot com]

------- Comment #3 from rob1weld at aol dot com  2008-08-04 17:21 -------
Created an attachment (id=16014)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16014&action=view)
gdiff of Origonal gcc-4.2.3/libjava/configure vs. repaired version

gdiff -Naur config_Origonal_configure.log config_Modified-1_configure.log >
diff_of_logs.gdiff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2008-08-04 18:53 -------
>The creator of the Operating System can name any command any name they want
> (EG: Ralph can be spelled Ralf or Rolf etc). Similarly grep can be called sed
> and sed can be called diff -- I'm not suggested that is a good idea, just that
> it is possible.

Not if they want to call their OS a POSIX or UNIX OS really.  POSIX actually
makes a standard about programs too.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
           Severity|major                       |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rob1weld at aol dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]



------- Comment #5 from rob1weld at aol dot com  2008-08-05 02:42 -------
Andrew Pinski  2008-08-04 18:53 wrote:
> Not if they want to call their OS a POSIX or UNIX OS really.  POSIX actually
> makes a standard about programs too.

If you want Posix conformant commands (not necessarily GNU programs) then the
Docs are here:

C(5)
http://docs.sun.com/app/docs/doc/819-2252/6n4i8rtov?l=en&a=view


It might be easier (for gcc) if we used GNU programs but if you would prefer
Posix and other Standards (certified by various groups) then here are a few
quotes from that Doc.


Solaris 10 supports IEEE Std 1003.1 and IEEE Std 1003.2, commonly known as
POSIX.1 and POSIX.2, respectively.


POSIX Standard          Description                              Release
POSIX.1–2001            POSIX.1-1990, POSIX.1b-1993, POSIX.1c-1996,
POSIX.2-1992, and POSIX.2a-1992 updates        Solaris 10 


Solaris 10 also supports the X/Open Common Applications Environment (CAE)
Portability Guide Issue 3 (XPG3) and Issue 4 (XPG4); Single UNIX Specification
(SUS, also known as XPG4v2); Single UNIX Specification, Version 2 (SUSv2); and
Single UNIX Specification, Version 3 (SUSv3). Both XPG4 and SUS include
Networking Services Issue 4 (XNS4). SUSv2 includes Networking Services Issue 5
(XNS5).


Utilities

      If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2
conflicts with historical Solaris utility behavior, the original Solaris
version of the utility is unchanged; a new version that is standard-conforming
has been provided in /usr/xpg4/bin. If the behavior required by POSIX.1–2001 or
SUSv3 conflicts with historical Solaris utility behavior, a new version that is
standard-conforming has been provided in /usr/xpg4/bin or in /usr/xpg6/bin. If
the behavior required by POSIX.1–2001 or SUSv3 conflicts with POSIX.2,
POSIX.2a, SUS, or SUSv2, a new version that is SUSv3 standard-conforming has
been provided in /usr/xpg6/bin.


We will need to check the "/usr/xpg4/bin" and "/usr/xpg6/bin" directories also
if you desire to use a program that meets a specific standard.

Or ...

We could just use GNU programs and require that the version number be greater
than X and less than Y and that all scripts work within those versions. Newer
series of gcc could permit newer version of the said utility program and old
versions of gcc could have patch sets made to permit some flexibility on the
range of versions permitted. This way we won't paint (program) ourselves into a
corner.


To me it seems easier to require GNU programs to compile GNU programs. This is
why I like to see the old compilers (gcc-3.4.3) working so we can bootstrap up
to the newer compilers (4.2.x series).

But when I'm running Solaris (and not Linux) I can use the "/usr/xpg4/bin" and
"/usr/xpg6/bin" programs (and the wonders of ZFS) too.


-- 

rob1weld at aol dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rob1weld at aol dot com]

------- Comment #6 from rob1weld at aol dot com  2008-08-05 05:07 -------
The grep/sed problem occurs during the boehm-gc configury and in
libjava/classpath also. It is also missing iconv whereas the main configure
picks it up (due to: "--with-libiconv-prefix=/opt/csw"):


Adding multilib support to Makefile in /aux0/gcc-4.2.3/libjava
multidirs=
with_multisubdir=
configure: configuring in classpath
...
checking for ld used by GCC... /usr/ccs/bin/ld
checking if the linker (/usr/ccs/bin/ld) is GNU ld... no
checking for shared library run path origin... /bin/bash:
/aux0/gcc-4.2.3/libjava/classpath/config.rpath: No such file or directory
done
checking for iconv... no, consider installing GNU libiconv
checking for X... libraries /usr/X11/lib, headers /usr/include/X11
checking whether -R must be followed by a space... no


Hopefully a new Autoconf is coming with a utility script (that will run through
all subdirectories searching for ".in" files and rebuild everything) -- that
anyone can run on any version of gcc or any GNU program (to save regressing
everything).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rwild at gcc dot gnu dot org]

------- Comment #7 from rwild at gcc dot gnu dot org  2008-08-05 06:50 -------
Rob, please let's not play ping pong with the severity of this bug.
Also, I haven't confirmed this one yet because while I see a couple
of problems, I don't see yet whether any of them is a regression
(this report is about the 4.2 branch which is in regression mode,
not trunk).

GCC does not assume that all commands are GNU commands, and that will
not change either.  GCC configury mostly assumes that available commands
respect POSIX with known limitations and bugs either listed in
gcc/doc/install.texi and/or in
<http://www.gnu.org/software/autoconf/manual/html_node/Portable-Shell.html>

To your config.log diff: how exactly did you create the two differing
versions?  Asking because they were quite obviously called with a different
command line.  Did you call one of them directly, and the other was what a
'make' from the top level caused to use?  Or did you try to build one in
stage1 and one in a later stage?

Then, the differing 'uname -v' output has nothing whatsoever to do with sed
or grep.  It is created purely by a line like this:

  uname -v = `(uname -v) 2>/dev/null || echo unknown`

The reason that one configure run fails is that it determines the compiler
to use solaris threads rather than posix threads; this is a consequence of
one configure run being with gcc, and one with the previously built compiler.

IOW, I currently don't yet understand how any of the problems you have should
have to do with sed or grep or other tools at all.  Please stick to describing
the actual problems rather than what you perceive them to be caused by: If you
follow the installation instructions of GCC, then when and how does it fail,
and what is the first (not last!) error seen plus the commands that led to it?

Thanks,
Ralf


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019

[Bug libgcj/37019] [4.2 Regression] Inconsistent gcc-4.2.3/libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[rob1weld at aol dot com]

------- Comment #8 from rob1weld at aol dot com  2008-08-05 16:59 -------
> Ralf Wildenhues  2008-08-05 wrote:
> Rob, please let's not play ping pong with the severity of this bug.
?

OK, I'll leave it with you.


> GCC configury mostly assumes that available commands respect POSIX

The default PATH (on unmodified Solaris) is:
PATH=/usr/sbin:/usr/bin

Traditional Sun utilities are in "/usr/bin" if you want "GNU programs" then
prefix with "g" and hope they are installed. If you want Posix programs then
look in "/usr/xpg4/bin" and/or in "/usr/xpg6/bin".


> To your config.log diff: how exactly did you create the two differing
> versions?  Asking because they were quite obviously called with a different
> command line.  Did you call one of them directly, and the other was what a
> 'make' from the top level caused to use?  Or did you try to build one in
> stage1 and one in a later stage?

The answer is in comment 2.

I compile gcc by typing "gmake" (comment 2 shows it's version).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019

[Bug libgcj/37019] libjava/configure uses "grep" and "egrep" and "grep -E" and "$EGGREP" but not ggrep -- sed also is trouble

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal
            Summary|[4.2 Regression]            |libjava/configure uses
                   |Inconsistent gcc-           |"grep" and "egrep" and "grep
                   |4.2.3/libjava/configure uses|-E" and "$EGGREP"  but not
                   |"grep" and "egrep" and "grep|ggrep -- sed also is trouble
                   |-E" and "$EGGREP"  but not  |
                   |ggrep -- sed also is trouble|


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019