GCC build failed with your patch on 2001-03-15T01:35:00Z.
Wed Mar 14 19:10:00 GMT 2001
I'm replying to two things at once...
On Wed, Mar 14, 2001 at 07:00:44PM -0800, Geoff Keating wrote:
> > From: "GCC regression checker" <email@example.com>
> > CC: firstname.lastname@example.org, email@example.com
> > Date: Thu, 15 Mar 2001 01:39:07 +0000
> > checking floating point format... configure: error: Unknown floating point format
> > Configure in /sloth/delay/tbox/build-gcc/gcc failed, exiting.
> Unfortunately, this test appears to rely on GNU grep, which does not
> come with solaris 2.6. I'm not sure what the problem with solaris
> grep is, I presume either it doesn't like NULs or it's not 8-bit
> clean. fgrep does seem to work, so perhaps you could use that?
I'm surprised fgrep works; those are regular expressions not fixed
strings. egrep maybe?
On Wed, Mar 14, 2001 at 09:50:23PM -0500, John Wehle wrote:
> I've had to make the following type of change to configure in order
> for things to work:
> if grep 'format::.@IEEEF.::tamrof' conftest.o >/dev/null 2>&1; then
> if strings -a conftest.o | grep 'format::.@IEEEF.::tamrof' >/dev/null 2>&1; then
> I'm not sure that grep likes binary files on all platforms.
I hesitate to do this for two reasons. Most simply, I'm not sure -a
is portable, and when I tried strings without -a, it didn't print
More subtly, there may be an unprintable character embedded in the
string, at a position where it should be matched by one of the dot
operators. strings will break it into two, and we won't get a
match. This is definitely the case with the PDP-10 float format where
all normalized numbers have the ninth bit of the second byte set.
More information about the Gcc-regression