My grep doesn't work against binary file on my Debian sid environment. % grep --version grep (GNU grep) 2.5.1 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. % grep grep `which grep` (no output) % I suggest that use 'strings' before grep: % strings `which grep` | grep grep `egrep' means `grep -E'. `fgrep' means `grep -F'. egrep fgrep %s (GNU grep) %s grep egrep fgrep %
Created attachment 7861 [details] [review] use strings before grep
How long before someone opens a bug that "my system doesn't have strings"? :)
(In reply to comment #0) > My grep doesn't work against binary file on my Debian sid environment. My first impulse is to believe that your grep is broken, so this isn't a cairo problem. The fact that you're running sid (where grep has been known to break in the past) makes me more suspicious. This "grepping a binary file for a string" approach has been used successfully by autoconf for years, so I'm even more likely to believe that we don't need to change anything on our end. That said, I'm OK with trying to make cairo work for broken greps if they happen in the wild and if it's not too much trouble for us. Can you try the -a option for grep? Beware of the garbage it'll spew when it hits a match. We don't have to worry about all that garbage in our macro, as we redirect the output. We really just care about the exit status. Oh, and have you verified that your broken grep gives the wrong exit status in your test case? You've shown that you get no output, but what about the exit status?
(In reply to comment #3) > That said, I'm OK with trying to make cairo work for broken greps if they happen > in the wild and if it's not too much trouble for us. Can you try the -a option > for grep? Beware of the garbage it'll spew when it hits a match. We don't have > to worry about all that garbage in our macro, as we redirect the output. We > really just care about the exit status. -a option worked: % grep -a grep `which grep` > /dev/null; echo $? 0 > Oh, and have you verified that your broken grep gives the wrong exit status in > your test case? You've shown that you get no output, but what about the exit status? % grep grep `which grep` > /dev/null; echo $? 1 % strings `which grep` | grep grep > /dev/null; echo $? 0
Created attachment 7891 [details] [review] Use 'strings -a' before grep 'strings' on its own doesn't work on Solaris but 'strings -a' does.
(In reply to comment #4) > (In reply to comment #3) > > That said, I'm OK with trying to make cairo work for broken greps if they happen > > in the wild and if it's not too much trouble for us. Can you try the -a option > > for grep? Beware of the garbage it'll spew when it hits a match. We don't have > > to worry about all that garbage in our macro, as we redirect the output. We > > really just care about the exit status. > > -a option worked: > % grep -a grep `which grep` > /dev/null; echo $? > 0 > That's really good news. So "strings" isn't needed after all. I'll go ahead and push out the "-a" addition once my freedesktop account clears (later today, hopefully).
Fixed. commit 392f27bf2b210aec6f511e5dba890d5f4c3b8802 Author: Dan Amelang <dan@amelang.net> Date: Sat Dec 2 11:02:36 2006 -0800 [configure] Add -a option to grep calls in AX_C_FLOAT_WORDS_BIGENDIAN
Unfortunately Solaris' grep doesn't have a -a option. Attached patch uses 'strings -a file | grep seesnoon'.
Created attachment 8068 [details] [review] Patch acinclude.m4 in 1.3.6 to use "strings -a | grep" for Solaris
This was brought up here already [9247], but I am starting to grow fond of the strings approach.
commit a87f494d4b91f3acc78d6d7dd737939633f28d71 Author: Dan Amelang <dan@amelang.net> Date: Tue Dec 12 16:34:50 2006 -0800 Don't use the GNU-only grep option "-a" We now use strings first, then grep to find the magic value, as suggested by various people in the reports for the bugs that this fixes: https://bugs.freedesktop.org/show_bug.cgi?id=9247 https://bugs.freedesktop.org/show_bug.cgi?id=9124
i have a problem with this using macosx 10.2/darwin 6 the current solution spits out the error configure:19773: checking whether byte ordering is bigendian configure:19805: gcc -c -arch ppc -g -Wall -pipe -no-cpp-precomp -Dsocklen_t= int -DMAC_OS_X_VERSION_MAX_ALLOWED=MAC_OS_X_VERSION_10_3 -I/tmp/cairo/Build/src -I/opt/local/include conftest.c >&5 configure:19811: $? = 0 configure:19843: gcc -c -arch ppc -g -Wall -pipe -no-cpp-precomp -Dsocklen_t= int -DMAC_OS_X_VERSION_MAX_ALLOWED=MAC_OS_X_VERSION_10_3 -I/tmp/cairo/Build/src -I/opt/local/include conftest.c >&5 configure:19849: $? = 0 configure:19989: result: yes configure:20008: checking whether float word ordering is bigendian configure:20045: gcc -c -arch ppc -g -Wall -pipe -no-cpp-precomp -Dsocklen_t= int -DMAC_OS_X_VERSION_MAX_ALLOWED=MAC_OS_X_VERSION_10_3 -I/tmp/cairo/Build/src -I/opt/local/include conftest.c >&5 configure:20051: $? = 0 configure:20079: result: unknown configure:20097: error: Unknown float word ordering. You need to manually preset ax_cv_c_float_words_bigendian=no (or yes) according to your system. it did work last week with the grep -a option
by putting double d = 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0; into a c file, and compiling it, it comes out short via strings [shadesofgray:/private/tmp] paul% strings -a crap.o |grep noonsees Exit 1 [shadesofgray:/private/tmp] paul% strings -a crap.o | grep noonsee noonsee however, xxd says all of noonsees is in there 0000180: 0000 0000 0000 0000 6e6f 6f6e 7365 6573 ........noonsees 0000190: 0000 0001 0f03 0000 0000 0000 005f 6400 ............._d. :\
perhaps the grep can be shortened to using regular expression ^noon for big endian and ^sees for little?
Created attachment 8145 [details] [review] diff to get it working for me again this works for me configure:20008: checking whether float word ordering is bigendian configure:20045: gcc -c -arch ppc -g -Wall -pipe -no-cpp-precomp -Dsocklen_t= int -DMAC_OS_X_VERSION_MAX_ALLOWED=MAC_OS_X_VERSION_10_3 -I/tmp/cairo/Build/src -I/opt/local/include conftest.c >&5 configure:20051: $? = 0 configure:20079: result: yes
comment to reopen bug
or maybe, if all the other platform's strings program has a - switch [shadesofgray:/private/tmp] paul% strings - crap.o __text __TEXT __picsymbolstub1__TEXT __data __DATA noonsees
Created attachment 8206 [details] [review] use - instead of -a gripe post with patch
The "-" option also seems to work for me on all platforms that I have at my disposal, so I've pushed out the change. commit 26b06516a77fbbe88f2eb081e2763c1434959137 Author: Dan Amelang <dan@amelang.net> Date: Sat Dec 30 21:14:14 2006 -0800 Use the "-" option (instead of "-a") when calling "strings" This is needed to fix the AX_C_FLOAT_WORDS_BIGENDIAN macro on Mac OS X 10.2, which was brought up here: https://bugs.freedesktop.org/show_bug.cgi?id=9124
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.