Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
From: M4um AT aol DOT com
Message-ID: <81.5134674.2785d47a@aol.com>
Date: Thu, 4 Jan 2001 08:28:26 EST
Subject: Re: #includes not being processed across network (revised)
To: cygwin AT cygwin DOT com
CC: flognat AT flognat DOT myip DOT org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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