Andy:
> Unfortunetaly I missed the first passes of the discussion, just some
> thoughts..
>
> If you throw the flag -v on gcc when you compile it tells you where it
> searches for include-files and which it finds.
>
> Throw your commandline in this direction and I can see if I can help
> you further.
Thanks; here's my command line:
gcc -save-temps -H -dD -g -v -O3 -m486 -I/usr/include -idirafter
/cygdrive/h/usr/include ./dcheck.c -o /usr/bin/dcheck
Notice the use of -v, along with -H, -dD and -save-temps to provide the
following:
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/specs
gcc version 2.95.2-6 19991024 (cygwin experimental)
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/cpp.exe -lang-c -v -I/usr/include
-D__GNUC__=2 -D__GNUC_MINOR__=95 -Di386 -D__386__ -D__i386 -D_X86=1
-D__STDC__=1 -D__stdcall=__attribute__((__stdcall__))
-D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x))
-D__i386__ -D__386__ -D__i386 -D_X86=1 -D__STDC__=1
-D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__))
-D__declspec(x)=__attribute__((x)) -D__i386 -Asystem(winnt) -Acpu(i386)
-Amachine(i386) -D__OPTIMIZE__ -g -H -dD -remap -Acpu(i386) -Amachine(i386)
-Di386 -D__i386 -D__i386__ -Di486 -D__i486 -D__i486__ -D__CYGWIN32__
-D__CYGWIN__ -Dunix -D__unix__ -D__unix -isystem /usr/local/include
-idirafter /usr/include -D_WIN32 -DWINNT -idirafter /usr/include/w32api
-idirafter /cygdrive/h/usr/include ./dcheck.c dcheck.i
GNU CPP version 2.95.2-6 19991024 (cygwin experimental) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/include
/usr/include
/usr/include/w32api
/cygdrive/h/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/../../../../include/g++-3
End of omitted list.
/usr/include/isglobal.h
/usr/include/stdio.h
/usr/include/_ansi.h
/usr/include/sys/config.h
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/include/stddef.h
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/include/stdarg.h
/usr/include/sys/reent.h
/usr/include/time.h
/usr/include/machine/time.h
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/include/stddef.h
/usr/include/sys/types.h
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/include/stddef.h
/usr/include/machine/types.h
/usr/include/sys/features.h
/usr/include/errno.h
/usr/include/sys/errno.h
/usr/include/disam.h
/usr/include/isport.h
/cygdrive/h/usr/include/CXlinkspec.h <== NOTE: FILE WITH #error AS FIRST
LINE! Comp should stop here.
/cygdrive/h/usr/include/isdecl.h
/cygdrive/h/usr/include/isdclint.h
/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/cc1.exe dcheck.i -quiet -dumpbase
dcheck.c -dD -m486 -g -O3 -version -o dcheck.s
GNU C version 2.95.2-6 19991024 (cygwin experimental) (i686-pc-cygwin)
compiled by GNU C version 2.95.2-6 19991024 (cygwin experimental).
(...COMPILE continues to errant output because CXlinkspec.h was not
processed)
AFTERWARDS the dcheck.i file contains (blank lines suppressed):
# 1 "./dcheck.c"
# 1 "/usr/include/isglobal.h" 1 3
(...many lines suppressed for length ... see list of #includes above)
# 1 "/usr/include/isport.h" 1 3
#define ISDECL
typedef char S8;
# 31 "/usr/include/disam.h" 2 3
# 1 "/cygdrive/h/usr/include/CXlinkspec.h" 1 3
# 41 "/usr/include/disam.h" 2 3
dll_data U32 isrecnum;
dll_data int isreclen;
(...compile continues ...)
THE numbers following each #include indicate "going to" and "returning from"
statuses, and they can be quite confusing.
NOTE how the line at CXlinkspec.h is followed immediately by disam.h. This
is very odd. In a full listing, a .i file contains many blank lines,
essentially one for each comment, etc., which is not part of the "active" .i
information; #defines, etc., appear whenever they are actually used. And the
first line of CXlinkspec is a #error instruction, which should have aborted
all further processing.
If I move the CXlinkspec.h from /cygdrive/h to cygdrive/c (the windows
machine) the compiler likewise finds the file there, and the #error causes it
to properly abort processing at that point.
Any ideas of others tests I can run to help isolate this problem? I admit
that it is most likely in my environment, but the fact that I am not getting
any sort of error message when the CXlinkspec.h is found but not processed
seems very telling.
Thanks,
John
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
