From: Soren A. <so...@wo...> - 2000-12-18 00:51:57
|
[ "japh" = "just another perl hack"] Hello MinGW-List, I have been up to more monkey-business ;-) and want to solicit feedback from users about my latest production. If one asks a question about "a bug" in gcc on this List or on the Cygwin List (right Earnie?) one will often be asked to give the output of a command like this one: touch foo.c && gcc --verbose -c foo.c - and the result looks like .. something messy (I was going to use a tastelessly graphic digestive-system analogy ..). Some of us don't always get away with not having our eyes cross in their sockets and a state of unconciousness begin to come on us when we've been hacking for 12 hours and we must then look at something like this, intently, trying to figure out if it tells us where a problem lies .. I've cobbled togwether a little Perl to make something readable (easy on the eyes for us faint-hearted souls) out of that output. My system gives this, tonight: ---- output --- cut here ---- Reading specs from D:\MinGW32\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\specs gcc version 2.95.2 19991024 (release) ------------------------------------------------------------------------ D:\MinGW32\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\cpp.exe ------------------------------------------------------------------------ Shows us: -D__GNUC__=2 -D__GNUC_MINOR__=95 -Di386 -D_WIN32 -DWIN32 -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -DWINNT -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D_stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -D__WINNT__ -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D___stdcall__=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386 -D__WIN32 -D__WINNT -D___stdcall=__attribute__((__stdcall__)) -Asystem(winnt) -Acpu(i386) -Amachine(i386) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ GNU CPP version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: D:\MinGW32\gcc-2.95.2\include D:\MinGW32\gcc-2.95.2\i386-mingw32msvc\include D:\MinGW32\gcc-2.95.2\lib\gcc-lib\i386-mingw32msvc\2.95.2\include End of search list. The following default directories have been omitted from the search path: /gcc-2.95.2/lib/gcc-lib/i386-mingw32msvc/2.95.2/../../../../include/g++-3 /usr/local/i386-mingw32/include End of omitted list. ------------------------------------------------------------------------ GNU C version 2.95.2 19991024 (release) (i386-mingw32msvc) compiled by: GNU C version 2.95.2 19991024 (release). ------------------------------------------------------------------------ -- end output --- cut here -- Does this seem like all the information that one normally wants to see? In othe words, look at it (please) critically as if you were diagnosing a cc fatal error that happened while building a package .. there are a few bits of text removed (but that and line wrapping is not all it does; it importantly -- to me -- 'collapses' redundant concatonated '../' pieces of paths) .. vis-a-vis the standard unpretty gush output from gcc. I want to know if this comprises satisfactorily complete output in the opinion of those more knowledgeable than myself, before I release it ("it" being my little perl hack, "gcc_spec_check.pl"). The program would be invoked like this BTW: $ gcc_spec_check.p - iow, very simple to "run". TIA, soren andersen |