public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Re: #includes not being processed across network (revised)
@ 2001-01-05  7:20 M4um
  2001-01-05  7:41 ` Larry Hall (RFK Partners, Inc)
  0 siblings, 1 reply; 25+ messages in thread
From: M4um @ 2001-01-05  7:20 UTC (permalink / raw)
  To: cygwin

I think I've discovered the root of the problem!  In reviewing the strace I 
realized that the st_size reported from fstat() is always zero for any file 
referrenced across the network. No read()s are subsequently done because 
there is (reportedly) no data!

Furthermore, if I do an "ls -l" of networked files from Cygwin/bash or sh, 
all the files are reported to be of size 0.  This is not the case when I do a 
"dir" from MS-DOS or open the H: folder from Windows: they report the size 
correctly.

Opinions, please: Is this standard operation of fstat() in this situation or 
does it suggest a bug?  Could it be a variable-size mismatch within the 
TCP/IP stack generated by the Unix file-server? Is there any way that my 
environment could be causing this -- any network settings that would affect 
fstat() here but not in the ls -l -- that I can pursue?  (cygcheck output 
follows)

Here's the strace:
**********************************************
Program name: D:\CYGWIN\BIN\GCC.EXE (612089)
App version:  1001.6, api: 0.30
DLL version:  1001.7, api: 0.31
DLL build:    2000-12-25 12:39
OS version:   Windows 98-4.10
Date/Time:    2001-01-04 10:24:15
**********************************************
  :  (lines suppressed)
  :
HERE the CXlinspec file gets opened as file# 4: 

  340 1440618 [main] cpp 607053 _open: 4 = open 
(/UNIX/usr/include/CXlinkspec.h, 0x20000)
 1938 1442556 [main] cpp 607053 fhandler_disk_file::fstat: 1 = 
GetFileInformationByHandle (H:\usr\include\CXlinkspec.h, 80)
  392 1442948 [main] cpp 607053 fhandler_disk_file::fstat: 0 = fstat (, 
0xC62B35C) st_atime=3A5497AD st_size=0, st_mode=0x81A4, st_ino=418540233, 
sizeof=64

NOTE that st_size == 0.  It should be 1627 bytes.

  566 1443514 [main] cpp 607053 _fstat: 0 = fstat (4, C62B35C)
  431 1443945 [main] cpp 607053 _cygwin_istext_for_stdio: 
_cygwin_istext_for_stdio (2)
  328 1444273 [main] cpp 607053 _cygwin_istext_for_stdio:  _cifs: get_*_binary
  323 1444596 [main] cpp 607053 setmode_helper: setmode: file was cle now raw
  322 1444918 [main] cpp 607053 setmode: setmode (2, binary) returns text
  325 1445243 [main] cpp 607053 _write: write (2, 0x255EEBC, 34)   
  322 1445565 [main] cpp 607053 fhandler_base::write: binary write
  351 1445916 [main] cpp 607053 fhandler_base::write: 34 = write (0x255EEBC, 
34)
  331 1446247 [main] cpp 607053 _write: 34 = write (2, 0x255EEBC, 34)
  323 1446570 [main] cpp 607053 _cygwin_istext_for_stdio: 
_cygwin_istext_for_stdio (2)
  319 1446889 [main] cpp 607053 _cygwin_istext_for_stdio: 
_cygwin_istext_for_stdio says yes
  324 1447213 [main] cpp 607053 setmode_helper: setmode: file was raw now cle
  323 1447536 [main] cpp 607053 setmode: setmode (2, text) returns binary

NOW it closes CXlinkspec.h without processing it, since it thinks that there 
are 0 bytes to read

  889 1448425 [main] cpp 607053 _close: close (4)
  317 1448742 [main] cpp 607053 fhandler_base::close: handle 0x50
  564 1449306 [main] cpp 607053 _close: 0 = close (4)

... and continues on as if nothing has happened
100370 1549676 [main] cpp 607053 _open: open 
(/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/include/isdecl.h, 0x20000)
  434 1550110 [main] cpp 607053 dtable::build_fhandler: some disk file - cb 
56, fd 4, fh 0xC581DA0
   :  (lines suppressed)
   :
   315 20348084 [main] gcc 612089 _pinfo::exit: Calling ExitProcess 1

*************

Cygnus Win95/NT Configuration Diagnostics
Current System Time: Fri Jan  5 10:07:26 2001

Win9X Ver 4.10 build 67766222  

Path:   /usr/local/bin
    /usr/bin
    /bin
    /cygdrive/c/WINDOWS
    /cygdrive/c/WINDOWS/COMMAND
    /usr/bin

SysDir: C:\WINDOWS\SYSTEM
WinDir: C:\WINDOWS

USER = `root'
HOME = `/cygdrive/d'
PWD = `/UNIX'
MAKE_MODE = `unix'

MACHTYPE = `i686-pc-cygwin'
HOSTNAME = `SEAN'
SHLVL = `1'
OLDPWD = `/UNIX/usr'
PROMPT = `$p$g'
PS1 = `\[\033]0;\007\033[33m\w\033[0m\]# '
_ = `cygcheck'
TEMP = `/cygdrive/c/Windows/TEMP'
WINBOOTDIR = `C:\WINDOWS'
TERM = `cygwin'
WINDIR = `C:\WINDOWS'
CMDLINE = `bash --login -i'
BLASTER = `A220 I5 D1 T4'
!D: = `D:\Cygwin\bin'
SHELL = `/bin/sh'
!H: = `H:\usr\vision\bin\pctools\en_US\visionfs'
CLASSPATH = `C:\Program Files\PhotoDeluxe 2.0\AdobeConnectables'
OSTYPE = `cygwin'
COMSPEC = `C:\WINDOWS\COMMAND.COM'
HOSTTYPE = `i686'
TZ = `EST5EDT4,M4.1.0/2,M10.5.0/2'

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder

\Start Menu\&Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x00000020
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\08
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\09
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0A
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0B
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0C
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0D
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0E
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0F
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\10
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\11
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\12
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\13
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\14
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\15
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\16
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\17
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\18
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\19
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1A
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1B
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1C
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1D
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `D:\Cygwin'
  flags = 0x00000008
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/crc
  (default) = `D:\Cygwin\usr\crc'
  flags = 0x00000008
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/UNIX
  (default) = `H:'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `D:\Cygwin\bin'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `D:\Cygwin\lib'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\1.00.000
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\08
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\09
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0A
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0B
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0C
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0D
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0E
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0F
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\10
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\11
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\12
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\13
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\14
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\15
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\16
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\17
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\18
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\19
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1A
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1B
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1C
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1D

a:  fd           N/A    N/A                    
c:  hd  FAT32   6850Mb  37% CP    UN           WINDOWS98
d:  hd  FAT32   6169Mb  45% CP    UN           CRC DRIVE
e:  cd           N/A    N/A                    
f:  fd           N/A    N/A                    
g:  cd           N/A    N/A                    
h:  net VFSU    3869Mb  40% CP    UN           root

D:\Cygwin\usr\crc  /usr/crc  system  textmode
D:\Cygwin\bin  /usr/bin  system  binmode
D:\Cygwin\lib  /usr/lib  system  binmode
D:\Cygwin  /        system  textmode
H:    /UNIX    system  binmode

Found: D:\Cygwin\bin\bash.exe
Found: D:\Cygwin\bin\cat.exe
Found: D:\Cygwin\bin\cpp.exe
Found: D:\Cygwin\bin\find.exe
Found: c:\WINDOWS\COMMAND\find.exe
Warning: D:\Cygwin\bin\find.exe hides c:\WINDOWS\COMMAND\find.exe
Found: D:\Cygwin\bin\gcc.exe
Found: D:\Cygwin\bin\gdb.exe
Found: D:\Cygwin\bin\ld.exe
Found: D:\Cygwin\bin\ls.exe
Found: D:\Cygwin\bin\make.exe
Found: D:\Cygwin\bin\sh.exe
Found: \bin\sh.exe
Warning: D:\Cygwin\bin\sh.exe hides \bin\sh.exe

   81k 2000/12/05 D:\Cygwin\bin\cygitcl30.dll - os=4.0 img=1.0 sys=4.0
                  "cygitcl30.dll" v0.0 ts=2000/11/25 20:43
   35k 2000/12/05 D:\Cygwin\bin\cygitk30.dll - os=4.0 img=1.0 sys=4.0
                  "cygitk30.dll" v0.0 ts=2000/11/25 20:43
  390k 2000/12/05 D:\Cygwin\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtcl80.dll" v0.0 ts=2000/11/25 20:39
    5k 2000/12/05 D:\Cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
   10k 2000/12/05 D:\Cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtclreg80.dll" v0.0 ts=2000/11/25 20:39
  623k 2000/12/05 D:\Cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtk80.dll" v0.0 ts=2000/11/25 20:43
  611k 2000/12/25 D:\Cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=2000/12/25 12:39
    Cygwin DLL version info:
        dll major: 1001
        dll minor: 7
        dll epoch: 19
        dll bad signal mask: 19005
        dll old termios: 5
        dll malloc env: 28
        api major: 0
        api minor: 31
        shared data: 3
        dll identifier: cygwin1
        mount registry: 2
        cygnus registry name: Cygnus Solutions
        cygwin registry name: Cygwin
        program options name: Program Options
        cygwin mount registry name: mounts v2
        cygdrive flags: cygdrive flags
        cygdrive prefix: cygdrive prefix
        cygdrive default prefix: 
        build date: Mon Dec 25 12:39:48 EST 2000
        shared id: cygwin1S3

Use -h to see help about each section

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-05  7:20 #includes not being processed across network (revised) M4um
@ 2001-01-05  7:41 ` Larry Hall (RFK Partners, Inc)
  2001-01-05  8:01   ` Markus Hoenicka
  0 siblings, 1 reply; 25+ messages in thread
From: Larry Hall (RFK Partners, Inc) @ 2001-01-05  7:41 UTC (permalink / raw)
  To: M4um, cygwin

At 10:20 AM 1/5/2001, M4um@aol.com wrote:
>I think I've discovered the root of the problem!  In reviewing the strace I 
>realized that the st_size reported from fstat() is always zero for any file 
>referrenced across the network. No read()s are subsequently done because 
>there is (reportedly) no data!
>
>Furthermore, if I do an "ls -l" of networked files from Cygwin/bash or sh, 
>all the files are reported to be of size 0.  This is not the case when I do a 
>"dir" from MS-DOS or open the H: folder from Windows: they report the size 
>correctly.
>
>Opinions, please: Is this standard operation of fstat() in this situation or 
>does it suggest a bug?  Could it be a variable-size mismatch within the 
>TCP/IP stack generated by the Unix file-server? Is there any way that my 
>environment could be causing this -- any network settings that would affect 
>fstat() here but not in the ls -l -- that I can pursue?  (cygcheck output 
>follows)


Hm, interesting and a good catch.  My guess is that there is some information
that comes across differently in your network case at least.  Can anyone 
verify that this is an issue for a typical Samba case for example?  It would
be interesting to know if this is a general network problem with Cygwin or 
if it is configuration specific.


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-05  7:41 ` Larry Hall (RFK Partners, Inc)
@ 2001-01-05  8:01   ` Markus Hoenicka
  2001-01-05  8:26     ` Larry Hall (RFK Partners, Inc)
  0 siblings, 1 reply; 25+ messages in thread
From: Markus Hoenicka @ 2001-01-05  8:01 UTC (permalink / raw)
  To: cygwin

File sizes are reported ok here for a Samba network drive, regardless
of whether I cd to /cygdrive/o and then ls -al or whether I mount the
remote drive and then run ls -al. This does not seem to be a CygWin
problem.

regards,
Markus

Larry Hall (RFK Partners, Inc) writes:
 > Hm, interesting and a good catch.  My guess is that there is some information
 > that comes across differently in your network case at least.  Can anyone 
 > verify that this is an issue for a typical Samba case for example?  It would
 > be interesting to know if this is a general network problem with Cygwin or 
 > if it is configuration specific.

-- 
Markus Hoenicka, PhD
UT Houston Medical School
Dept. of Integrative Biology and Pharmacology
6431 Fannin MSB4.114
Houston, TX 77030
(713) 500-6313, -7477
(713) 500-7444 (fax)
Markus.Hoenicka@uth.tmc.edu
http://ourworld.compuserve.com/homepages/hoenicka_markus/


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-05  8:01   ` Markus Hoenicka
@ 2001-01-05  8:26     ` Larry Hall (RFK Partners, Inc)
  2001-01-05  8:42       ` Ray Easton
  0 siblings, 1 reply; 25+ messages in thread
From: Larry Hall (RFK Partners, Inc) @ 2001-01-05  8:26 UTC (permalink / raw)
  To: Markus Hoenicka, cygwin

Thanks Markus, this information is quite helpful.  Since there isn't an issue 
with Samba, the Win32 APIs being used in Cygwin are clearly sufficient to 
provide the information required (i.e. file sizes in this case) in a network 
environment in general.  However, in this particular case in this particular 
network environment, there may be an issue.  I would guess that there is 
either a problem with permissions (which John has stated that he's looked at 
before) or there is some other Win32 API that provides the file size even with 
John's setup (which the DOS tools use and Cygwin does not).  What is clear to
me by all this is that the quickest way to resolve this issue is to debug the
code, for better or worse...

Larry

At 11:11 AM 1/5/2001, Markus Hoenicka wrote:
>File sizes are reported ok here for a Samba network drive, regardless
>of whether I cd to /cygdrive/o and then ls -al or whether I mount the
>remote drive and then run ls -al. This does not seem to be a CygWin
>problem.
>
>regards,
>Markus
>
>Larry Hall (RFK Partners, Inc) writes:
>  > Hm, interesting and a good catch.  My guess is that there is some information
>  > that comes across differently in your network case at least.  Can anyone 
>  > verify that this is an issue for a typical Samba case for example?  It would
>  > be interesting to know if this is a general network problem with Cygwin or 
>  > if it is configuration specific.
>
>-- 
>Markus Hoenicka, PhD
>UT Houston Medical School
>Dept. of Integrative Biology and Pharmacology
>6431 Fannin MSB4.114
>Houston, TX 77030
>(713) 500-6313, -7477
>(713) 500-7444 (fax)
>Markus.Hoenicka@uth.tmc.edu
> http://ourworld.compuserve.com/homepages/hoenicka_markus/
>
>
>--
>Want to unsubscribe from this list?
>Check out: http://cygwin.com/ml/#unsubscribe-simple



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-05  8:26     ` Larry Hall (RFK Partners, Inc)
@ 2001-01-05  8:42       ` Ray Easton
  2001-01-05  8:52         ` Larry Hall (RFK Partners, Inc)
  0 siblings, 1 reply; 25+ messages in thread
From: Ray Easton @ 2001-01-05  8:42 UTC (permalink / raw)
  To: cygwin

"Larry Hall (RFK Partners, Inc)" wrote:

> Thanks Markus, this information is quite helpful.  Since there isn't an issue
> with Samba, the Win32 APIs being used in Cygwin are clearly sufficient to
> provide the information required (i.e. file sizes in this case) in a network
> environment in general.  However, in this particular case in this particular
> network environment, there may be an issue.  I would guess that there is
> either a problem with permissions (which John has stated that he's looked at
> before) or there is some other Win32 API that provides the file size even with
> John's setup (which the DOS tools use and Cygwin does not).  What is clear to
> me by all this is that the quickest way to resolve this issue is to debug the
> code, for better or worse...
>
> Larry

I've seen fstat() returning zero problems many times in many contexts (though *not*
with cygwin) and in each case it has been due to bugs in the file server software --
in which case debugging cygwin code will be useless.  The quickest way to resolve the
issue is more likely simply to replace the file server software.

--

ray

    -- je suis marxiste, tendance groucho



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-05  8:42       ` Ray Easton
@ 2001-01-05  8:52         ` Larry Hall (RFK Partners, Inc)
  0 siblings, 0 replies; 25+ messages in thread
From: Larry Hall (RFK Partners, Inc) @ 2001-01-05  8:52 UTC (permalink / raw)
  To: Ray Easton, cygwin

At 11:39 AM 1/5/2001, Ray Easton wrote:
>"Larry Hall (RFK Partners, Inc)" wrote:
>
> > Thanks Markus, this information is quite helpful.  Since there isn't an issue
> > with Samba, the Win32 APIs being used in Cygwin are clearly sufficient to
> > provide the information required (i.e. file sizes in this case) in a network
> > environment in general.  However, in this particular case in this particular
> > network environment, there may be an issue.  I would guess that there is
> > either a problem with permissions (which John has stated that he's looked at
> > before) or there is some other Win32 API that provides the file size even with
> > John's setup (which the DOS tools use and Cygwin does not).  What is clear to
> > me by all this is that the quickest way to resolve this issue is to debug the
> > code, for better or worse...
> >
> > Larry
>
>I've seen fstat() returning zero problems many times in many contexts (though *not*
>with cygwin) and in each case it has been due to bugs in the file server software --
>in which case debugging cygwin code will be useless.  The quickest way to resolve the
>issue is more likely simply to replace the file server software.


No argument here with regards to the quick solution proposed.  It appears 
that Samba functions quite nicely so I expect converting to use that as the
file server is a quicker solution (with a more time-tested outcome). 





Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
@ 2001-01-08  8:17 M4um
  0 siblings, 0 replies; 25+ messages in thread
From: M4um @ 2001-01-08  8:17 UTC (permalink / raw)
  To: cygwin

I replaced VisionFS on the Unix box with SAMBA and the problem has been 
corrected -- file sizes are being properly reported through ls -l and through 
fstat() calls.

We may have to return to VisionFS for other reasons once the production 
environment is fully fleshed out, but I just learned that there is a new 
version available which may be more compatible.  At least we know what to 
watch for.

Thanks for all you help.

John McDonald  

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-04 12:49 M4um
@ 2001-01-04 12:56 ` Christopher Faylor
  0 siblings, 0 replies; 25+ messages in thread
From: Christopher Faylor @ 2001-01-04 12:56 UTC (permalink / raw)
  To: cygwin

On Thu, Jan 04, 2001 at 03:48:24PM -0500, M4um@aol.com wrote:
>Earnie:
>>The only other thing I can think of is to use gdb.  You'll need to get
>>the source and build a debug version of cygwin1.dll so you can step
>>into the functions.
>
>While I can do the debug, I'm afraid that building debuggable dlls and
>cpp's is beyond my resources.  Unless you know someone out there better
>equipped who can assist me, my employers may insist that I find another
>market path to Windows.

Maybe this is the best solution, then.

>Can you recommend someone?

I don't mean to speak for Earnie but I'm not sure what you are asking
for.  Are you looking for a consultant?  As you know mailing list
participation is entirely voluntary.  This is a very helpful list but I
would not expect anyone to debug your problem for you.

Btw, I should point out that if you are actually going to be selling
software based on cygwin, it must be GPLed.  That is how the cygwin
licensing works.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
@ 2001-01-04 12:49 M4um
  2001-01-04 12:56 ` Christopher Faylor
  0 siblings, 1 reply; 25+ messages in thread
From: M4um @ 2001-01-04 12:49 UTC (permalink / raw)
  To: cygwin

Earnie:

> The only other thing I can think of is to use gdb.  You'll need to get
>  the source and build a debug version of cygwin1.dll so you can step into
>  the functions.

While I can do the debug, I'm afraid that building debuggable dlls and cpp's 
is beyond my resources.  Unless you know someone out there better equipped 
who can assist me, my employers may insist that I find another market path to 
Windows.

Can you recommend someone?

John 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-04  8:24 M4um
@ 2001-01-04  9:38 ` Earnie Boyd
  0 siblings, 0 replies; 25+ messages in thread
From: Earnie Boyd @ 2001-01-04  9:38 UTC (permalink / raw)
  To: M4um; +Cc: cygwin, flognat, Larry Hall (RFK Partners, Inc)

M4um@aol.com wrote:
> 
> There is nothing that I can find between the time the CXlinkspec.h is opened
> and the time it is closed to indicate what has gone wrong.  Any further tests
> you can suggest?
> 

The only other thing I can think of is to use gdb.  You'll need to get
the source and build a debug version of cygwin1.dll so you can step into
the functions.

Cheers,
Earnie.

P.S.: Don't add me to the CC list.  I use the Reply-to feature on
purpose.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
@ 2001-01-04  8:24 M4um
  2001-01-04  9:38 ` Earnie Boyd
  0 siblings, 1 reply; 25+ messages in thread
From: M4um @ 2001-01-04  8:24 UTC (permalink / raw)
  To: cygwin; +Cc: Earnie Boyd, flognat, Larry Hall (RFK Partners, Inc)

Earnie:

> It sounds as if it's time to strace.  Expect the strace file to be
>  large.  Compare between the one that works and the one that doesn't.

Here's the CXlinkspec part of strace:
**********************************************
Program name: D:\CYGWIN\BIN\GCC.EXE (612089)
App version:  1001.6, api: 0.30
DLL version:  1001.7, api: 0.31
DLL build:    2000-12-25 12:39
OS version:   Windows 98-4.10
Date/Time:    2001-01-04 10:24:15
**********************************************
  :  (lines suppressed)
  :
  344 1431898 [main] cpp 705197 _open: -1 = open 
(/UNIX/usr/include/header.gcc, 0x0)

(NOTE: I have no idea what header.gcc is or how it applies to this problem.)

   331 1432229 [main] cpp 607053 _open: open (/UNIX/usr/include/CXlinkspec.h, 
0x20000)
  342 1432571 [main] cpp 607053 dtable::build_fhandler: some disk file - cb 
56, fd 4, fh 0xC581DA0
  323 1432894 [main] cpp 607053 fhandler_disk_file::open: 
(/UNIX/usr/include/CXlinkspec.h, 0x20000)
  333 1433227 [main] cpp 607053 mount_info::conv_to_win32_path: 
conv_to_win32_path (/UNIX/usr/include/CXlinkspec.h)
  325 1433552 [main] cpp 607053 normalize_posix_path: src 
/UNIX/usr/include/CXlinkspec.h
  322 1433874 [main] cpp 607053 normalize_posix_path: 
/UNIX/usr/include/CXlinkspec.h = normalize_posix_path 
(/UNIX/usr/include/CXlinkspec.h)
  342 1434216 [main] cpp 607053 mount_info::conv_to_win32_path: 
H:\usr\include\CXlinkspec.h(rel), H:\usr\include\CXlinkspec.h(abs) 0xA(flags) 
= conv_to_win32_path (/UNIX/usr/include/CXlinkspec.h)
 1158 1435374 [main] cpp 607053 symlink_info::check: not a symlink
  326 1435700 [main] cpp 607053 symlink_info::check: 0 = symlink.check 
(H:\usr\include\CXlinkspec.h, 0x255EED1) (0xA)
  482 1436182 [main] cpp 607053 path_conv::check: GetVolumeInformation(H:\) = 
OK, full_path(H:\usr\include\CXlinkspec.h), set_has_acls(0)
  354 1436536 [main] cpp 607053 fhandler_base::open: 
(H:\usr\include\CXlinkspec.h, 0x20000)
 2029 1438565 [main] cpp 607053 fhandler_base::open: 80 = CreateFileA 
(H:\usr\include\CXlinkspec.h, 0x80000000, 0x3, 0x61084178, 0x3, 0x80, 0)
  350 1438915 [main] cpp 607053 fhandler_base::open: filemode set to text
  369 1439284 [main] cpp 607053 fhandler_base::open: 1 = fhandler_base::open 
(H:\usr\include\CXlinkspec.h, 0x20000)
  994 1440278 [main] cpp 607053 fhandler_disk_file::open: 1 = 
fhandler_disk_file::open (H:\usr\include\CXlinkspec.h, 0x20000)

HERE the CXlinspec file gets opened as file# 4: 
  340 1440618 [main] cpp 607053 _open: 4 = open 
(/UNIX/usr/include/CXlinkspec.h, 0x20000)
 1938 1442556 [main] cpp 607053 fhandler_disk_file::fstat: 1 = 
GetFileInformationByHandle (H:\usr\include\CXlinkspec.h, 80)
  392 1442948 [main] cpp 607053 fhandler_disk_file::fstat: 0 = fstat (, 
0xC62B35C) st_atime=3A5497AD st_size=0, st_mode=0x81A4, st_ino=418540233, 
sizeof=64
  566 1443514 [main] cpp 607053 _fstat: 0 = fstat (4, C62B35C)
  431 1443945 [main] cpp 607053 _cygwin_istext_for_stdio: 
_cygwin_istext_for_stdio (2)
  328 1444273 [main] cpp 607053 _cygwin_istext_for_stdio:  _cifs: get_*_binary
  323 1444596 [main] cpp 607053 setmode_helper: setmode: file was cle now raw
  322 1444918 [main] cpp 607053 setmode: setmode (2, binary) returns text
  325 1445243 [main] cpp 607053 _write: write (2, 0x255EEBC, 34)   
  322 1445565 [main] cpp 607053 fhandler_base::write: binary write
  351 1445916 [main] cpp 607053 fhandler_base::write: 34 = write (0x255EEBC, 
34)
  331 1446247 [main] cpp 607053 _write: 34 = write (2, 0x255EEBC, 34)
  323 1446570 [main] cpp 607053 _cygwin_istext_for_stdio: 
_cygwin_istext_for_stdio (2)
  319 1446889 [main] cpp 607053 _cygwin_istext_for_stdio: 
_cygwin_istext_for_stdio says yes
  324 1447213 [main] cpp 607053 setmode_helper: setmode: file was raw now cle
  323 1447536 [main] cpp 607053 setmode: setmode (2, text) returns binary

NOW, for some reason, it closes CXlinkspec.h without processing it! (should 
be "_read: read (4,", and a write ...)  
  889 1448425 [main] cpp 607053 _close: close (4)
  317 1448742 [main] cpp 607053 fhandler_base::close: handle 0x50
  564 1449306 [main] cpp 607053 _close: 0 = close (4)

... and continues on as if nothing has happened
100370 1549676 [main] cpp 607053 _open: open 
(/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2-6/include/isdecl.h, 0x20000)
  434 1550110 [main] cpp 607053 dtable::build_fhandler: some disk file - cb 
56, fd 4, fh 0xC581DA0
   :  (lines suppressed)
   :
  428 20345650 [main] gcc 612089 kill_pgrp: -1 = kill (612089, -1)
 1173 20346823 [main] gcc 612089 __to_clock_t: dwHighDateTime 0, 
dwLowDateTime 0
  315 20347138 [main] gcc 612089 __to_clock_t: total 00000000 00000000
  315 20347453 [main] gcc 612089 __to_clock_t: dwHighDateTime 0, 
dwLowDateTime 0
  316 20347769 [main] gcc 612089 __to_clock_t: total 00000000 00000000
  315 20348084 [main] gcc 612089 _pinfo::exit: Calling ExitProcess 1

There is nothing that I can find between the time the CXlinkspec.h is opened 
and the time it is closed to indicate what has gone wrong.  Any further tests 
you can suggest?

John

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-03 18:35 M4um
@ 2001-01-04  7:40 ` Larry Hall (RFK Partners, Inc)
  0 siblings, 0 replies; 25+ messages in thread
From: Larry Hall (RFK Partners, Inc) @ 2001-01-04  7:40 UTC (permalink / raw)
  To: M4um, cygwin; +Cc: Earnie Boyd

At 09:34 PM 1/3/2001, M4um@aol.com wrote:
>One other thought just struck me: Are #included files accessed by any 
>specific dll or bash/sh command or function that can be excersized or tested 
>independantly by some clever means?  It may be that I have something still 
>outdated in my installation that's fallen through the cracks.  (By the way, 
>since the last cygcheck I've upgraded the cygtcl dlls.) 


If you're concerned about having things up-to-date, just rerun setup.  It 
will update anything that's out-of-date.


>While I research how Samba will fit into our configuration, can you think of 
>any gcc/cpp tests that might help me isolate this problem?


Sounds to me like strace is your best bet, as Earnie suggested.


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-04  6:36 M4um
@ 2001-01-04  6:49 ` Earnie Boyd
  0 siblings, 0 replies; 25+ messages in thread
From: Earnie Boyd @ 2001-01-04  6:49 UTC (permalink / raw)
  To: M4um; +Cc: cygwin, flognat

M4um@aol.com wrote:
> 
> Earnie:
> 
> > >
> >  > 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
> >  >
> >
> >  What happens if you change the command line to
> >    gcc -save-temps -H -dD -g -v -O3 -m486 -I/usr/include -idirafter
> >    h:/usr/include  ./dcheck.c -o /usr/bin/dcheck
> >
> >  Don't you have H:/ mounted to /UNIX?  What about
> >    gcc -save-temps -H -dD -g -v -O3 -m486 -I/usr/include -idirafter
> >    /UNIX:/usr/include  ./dcheck.c -o /usr/bin/dcheck
> 
> I have tried these and various other pseudonyms for "over there" -- including
> a full mount directly to H:/usr/include, along with bin/textmode changes --
> with the same result: The file is always found, but it is not processed.
> 

It sounds as if it's time to strace.  Expect the strace file to be
large.  Compare between the one that works and the one that doesn't.

Cheers,
Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-04  6:27   ` Robert Collins
@ 2001-01-04  6:39     ` Earnie Boyd
  0 siblings, 0 replies; 25+ messages in thread
From: Earnie Boyd @ 2001-01-04  6:39 UTC (permalink / raw)
  To: Robert Collins; +Cc: cygwin

Robert Collins wrote:
> 
> >
> > Don't you have H:/ mounted to /UNIX?  What about
> >   gcc -save-temps -H -dD -g -v -O3 -m486 -I/usr/include -idirafter
> >   /UNIX:/usr/include  ./dcheck.c -o /usr/bin/dcheck
> >
>  ^^^^:^^^^
> is the : intentional?
> 

Oops, cut and paste error.  Sorry, it shouldn't be there.

Cheers,
Earnie.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
@ 2001-01-04  6:36 M4um
  2001-01-04  6:49 ` Earnie Boyd
  0 siblings, 1 reply; 25+ messages in thread
From: M4um @ 2001-01-04  6:36 UTC (permalink / raw)
  To: cygwin; +Cc: flognat

Earnie:

> >
>  > 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
>  >
>  
>  What happens if you change the command line to
>    gcc -save-temps -H -dD -g -v -O3 -m486 -I/usr/include -idirafter
>    h:/usr/include  ./dcheck.c -o /usr/bin/dcheck
>  
>  Don't you have H:/ mounted to /UNIX?  What about
>    gcc -save-temps -H -dD -g -v -O3 -m486 -I/usr/include -idirafter
>    /UNIX:/usr/include  ./dcheck.c -o /usr/bin/dcheck

I have tried these and various other pseudonyms for "over there" -- including 
a full mount directly to H:/usr/include, along with bin/textmode changes --  
with the same result: The file is always found, but it is not processed.

Thanks,
John

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-04  6:24 ` Earnie Boyd
@ 2001-01-04  6:27   ` Robert Collins
  2001-01-04  6:39     ` Earnie Boyd
  0 siblings, 1 reply; 25+ messages in thread
From: Robert Collins @ 2001-01-04  6:27 UTC (permalink / raw)
  To: cygwin

> 
> Don't you have H:/ mounted to /UNIX?  What about
>   gcc -save-temps -H -dD -g -v -O3 -m486 -I/usr/include -idirafter
>   /UNIX:/usr/include  ./dcheck.c -o /usr/bin/dcheck
> 
 ^^^^:^^^^
is the : intentional?


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-04  5:29 M4um
@ 2001-01-04  6:24 ` Earnie Boyd
  2001-01-04  6:27   ` Robert Collins
  0 siblings, 1 reply; 25+ messages in thread
From: Earnie Boyd @ 2001-01-04  6:24 UTC (permalink / raw)
  To: M4um; +Cc: cygwin, flognat

M4um@aol.com wrote:

>
> 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
>

What happens if you change the command line to
  gcc -save-temps -H -dD -g -v -O3 -m486 -I/usr/include -idirafter
  h:/usr/include  ./dcheck.c -o /usr/bin/dcheck

Don't you have H:/ mounted to /UNIX?  What about
  gcc -save-temps -H -dD -g -v -O3 -m486 -I/usr/include -idirafter
  /UNIX:/usr/include  ./dcheck.c -o /usr/bin/dcheck

Cheers,
Earnie.

P.S.: Getting rid of blank lines:
  sed -e 's/^[ <TAB>]*$//' foo.file > foo.newfile
Replace the <TAB> with a real tab character, in vi it is C-vC-i


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
@ 2001-01-04  5:29 M4um
  2001-01-04  6:24 ` Earnie Boyd
  0 siblings, 1 reply; 25+ messages in thread
From: M4um @ 2001-01-04  5:29 UTC (permalink / raw)
  To: cygwin; +Cc: flognat

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
@ 2001-01-03 18:35 M4um
  2001-01-04  7:40 ` Larry Hall (RFK Partners, Inc)
  0 siblings, 1 reply; 25+ messages in thread
From: M4um @ 2001-01-03 18:35 UTC (permalink / raw)
  To: cygwin; +Cc: lhall, Earnie Boyd

Larry:

>  >BTW: My arrangement of sources and headers across several different OSs 
is 
>  >not that unusual. We have C source code for libraries and apps under 
Unix, 
>  >and are preparing Windows console executables using Cygwin's gcc.  This 
>  >requires that the source code stay on the Unix box and #includes may be 
> found 
>  >on either machine as needed to orient the different compilers to their 
> native 
>  >OS. We will expand this to lynix, etc., as needed across the network, but 
>  >never disturbing the Unix-resident  source.  It's basically using a 
network 
> 
>  >instead of a cross-compiler.
>  
>  
>  This much I get!;-)

Okay ... Now imagine that you are running a Cygwin gcc compile under such a 
arrangement: the C source code  may be anywhere on the net, and there are 
#includes on both the Windows machine and Unix.  Any #included files it finds 
on the Windows box it processes OK; any #included files it finds on the Unix 
box -- and it tells you that it finds them -- are simply not processed, and 
there is no error message telling you "cannot access", "locked", etc.  THAT'S 
what I'm observing.

> You made a comment in your original message that lead me to believe that you
>  tried taking all the sources to some UNIX system and compiled it there with
>  gcc and saw the same problem.  Was that the wrong impression?  

No, I think we're miscommunicating ...  I have a Unix version of gcc running 
on the Unix box generating Unix apps; I wish to access these same sources 
from Cygwin and compile Windows versions.

> If so, then
>  it may be a gcc-on-Windows thing.  If not, it may be a generic gcc issue
>  or a problem with whatever VisionFS is and what it does for you.  I don't 
>  mean to suggest that you haven't configured VisionFS properly for your 
needs
>  but not knowing what this is, what it provides, and what parts are 
> interacting
>  with gcc makes it hard for anyone on this list to rule it out summarily.  
If
>  it provides access to its disks through some NFS server, for example, it 
>  would not be the first time that a problem was reported to this list along
>  this line where the issue was a problem with the way the NFS server 
worked. 
> There's also always the potential for interaction problems with heretofore 
>  unknown and untried software in combination with Cygwin (which this 
> qualifies
>  as AFAIK).  If there's reason to suspect an interaction problem here, you 
> may 
>  want to try installing a Samba server on your UNIX box and use that as the 
>  Windows file server.  People using Cygwin have generally had luck with 
that.

Yes, I understand that this may be a "new" combination -- Cygwin gcc on Win98 
+ SCO's VFSU.  That's one of the reasons I posted here: in the hopes that 
someone may have used this combination before and might be able to offer an 
experienced hand.
 
I'll look into the possibility of using Samba.

>  Its also worthwhile to note that while Cygwin is a platform that supports
>  gcc on Windows (and probably the most convenient one for you given the 
>  origin of your source). There is also a native Windows port that doesn't
>  require Cywgin at all (see www.mingw.org).  You may want to test out your 
>  problem with this as well to see if you would be better served by another 
>  list found at gcc.gnu.org.

"Ming" is not an option at this time.  I have some time constraints and must 
deliver something that will run both apps and existing Unix scripts, at least 
in the short term.

One other thought just struck me: Are #included files accessed by any 
specific dll or bash/sh command or function that can be excersized or tested 
independantly by some clever means?  It may be that I have something still 
outdated in my installation that's fallen through the cracks.  (By the way, 
since the last cygcheck I've upgraded the cygtcl dlls.) 

While I research how Samba will fit into our configuration, can you think of 
any gcc/cpp tests that might help me isolate this problem?

Thanks,
John

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
@ 2001-01-03 18:32 M4um
  0 siblings, 0 replies; 25+ messages in thread
From: M4um @ 2001-01-03 18:32 UTC (permalink / raw)
  To: cygwin; +Cc: Earnie Boyd, lhall

Earnie:

>No one else has your environment.  You will have to
> debug this yourself, but we'll try to help with suggestions.

Thanks, in advance, for any help you can offer.

> Can other programs read the files?  E.G.: `cat /UNIX/foo.h' gives what
>  results?

Cat, less, vi, etc. all work as expected, even in parallel (simultaneous 
multiple accesses) under bash, "raw" sh and/or DOS commands ("type", etc).

>  Could it be a timing issue, or a permissions issue?  

Since I can access and modify files using both bash and "raw" sh, permissions 
would seem to be OK.  Locking appears to work properly, also.  Refering to 
cygcheck (previous email): the system understands me to be "root", a 
super-user. 

As far as "timing" goes, I've noticed on several occasions that there seems 
to be some file-timing anomalies within Cygwin.  For example, in a script 
(batch file) that has a number of steps, each ending in "> _log" in order to 
trace execution, I often lose part of the trace -- it appears as if the next 
step produces output into _log before the preceding step has flushed its 
contents into _log and closed the file.  

It seems reasonable that this anomaly -- if it really exists -- would be more 
likely to occur when working across a network because of the inherent 
hardware/software delay.  Remember that, in the #include problem I'm having, 
the #included file is being found by the cpp, but it is not being processed 
-- and there is no error message being generated.  This lack of message 
("cannot access", "not found", "locked", etc.) would seem to suggest 
something out of the ordinary.

> Are you using Cygwin
>  symlinks on your H: directory, that most likely won't work unless you
>  can emulate
>  the Win32 system file bit on your UNIX server.

No, until I get this straightened out I will differ from using any "soft 
links", DOS shortcuts or other redirections that might complicate the issue.

Any tests you can suggest that might help me isolate the problem?

Thanks,
John

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-03 13:38 M4um
  2001-01-03 14:16 ` Earnie Boyd
@ 2001-01-03 14:40 ` Larry Hall (RFK Partners, Inc)
  1 sibling, 0 replies; 25+ messages in thread
From: Larry Hall (RFK Partners, Inc) @ 2001-01-03 14:40 UTC (permalink / raw)
  To: M4um, cygwin

At 04:38 PM 1/3/2001, M4um@aol.com wrote:
>Larry:
>
> > If you're saying that this problem occurs if you move all the source to a
> >  UNIX machine and that the source is local on that machine (i.e. it doesn't
> >  somehow involve using the VisionFS file server stuff at all - I have no 
>idea  
> >  what this does for you), then I would say this is an issue with gcc tools 
> >  (well cpp to be exact).  If you only see the problems when using the file 
> >  server, then something about that setup/software is probably to blame.  In 
> >  the former case, you could send email to the gcc list.  In the latter, you 
> >  need to consult the providers of VisionFS.
>
>Pardon my ignorance, but isn't this the list that deals with gcc as it 
>applies to Cygwin? The problem is, by definition, environment-dependant. The 
>gcc, cpp and other Cygwin binaries are the "run side" of that environment; 
>the "read side" is a common network-drive mapped onto H: (and served by 
>VisionFS on the Unix box). If there is better list I'd gladly follow it, but 
>starting at gnu.org and going to "Windows->gcc->binaries" leads me back here.


You made a comment in your original message that lead me to believe that you
tried taking all the sources to some UNIX system and compiled it there with
gcc and saw the same problem.  Was that the wrong impression?  If so, then
it may be a gcc-on-Windows thing.  If not, it may be a generic gcc issue
or a problem with whatever VisionFS is and what it does for you.  I don't 
mean to suggest that you haven't configured VisionFS properly for your needs
but not knowing what this is, what it provides, and what parts are interacting
with gcc makes it hard for anyone on this list to rule it out summarily.  If
it provides access to its disks through some NFS server, for example, it 
would not be the first time that a problem was reported to this list along
this line where the issue was a problem with the way the NFS server worked. There's also always the potential for interaction problems with heretofore 
unknown and untried software in combination with Cygwin (which this qualifies
as AFAIK).  If there's reason to suspect an interaction problem here, you may 
want to try installing a Samba server on your UNIX box and use that as the 
Windows file server.  People using Cygwin have generally had luck with that.

Its also worthwhile to note that while Cygwin is a platform that supports
gcc on Windows (and probably the most convenient one for you given the 
origin of your source). There is also a native Windows port that doesn't
require Cywgin at all (see www.mingw.org).  You may want to test out your 
problem with this as well to see if you would be better served by another 
list found at gcc.gnu.org.


>That being said, can you suggest a test that would better define exactly 
>where the breakdown is occuring?  Remember that we are NOT getting any sort 
>of error message: the #included file is being found but not processed.  The 
>Unix side of the net has been exhaustively diag'ed and reconfigured in every 
>way imaginable, with the same results.  If you'll forgive the term, it 
>"smells" like there's a loss of syncronization somewhere in cpp. 


Definitely could be.


>BTW: My arrangement of sources and headers across several different OSs is 
>not that unusual. We have C source code for libraries and apps under Unix, 
>and are preparing Windows console executables using Cygwin's gcc.  This 
>requires that the source code stay on the Unix box and #includes may be found 
>on either machine as needed to orient the different compilers to their native 
>OS. We will expand this to lynix, etc., as needed across the network, but 
>never disturbing the Unix-resident  source.  It's basically using a network 
>instead of a cross-compiler.


This much I get!;-)

Good luck,


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-03 13:38 M4um
@ 2001-01-03 14:16 ` Earnie Boyd
  2001-01-03 14:40 ` Larry Hall (RFK Partners, Inc)
  1 sibling, 0 replies; 25+ messages in thread
From: Earnie Boyd @ 2001-01-03 14:16 UTC (permalink / raw)
  To: M4um; +Cc: cygwin, lhall

M4um@aol.com wrote:

> Larry:
>
> > If you're saying that this problem occurs if you move all the source to a
> >  UNIX machine and that the source is local on that machine (i.e. it doesn't
> >  somehow involve using the VisionFS file server stuff at all - I have no
> idea
> >  what this does for you), then I would say this is an issue with gcc tools
> >  (well cpp to be exact).  If you only see the problems when using the file
> >  server, then something about that setup/software is probably to blame.  In
> >  the former case, you could send email to the gcc list.  In the latter, you
> >  need to consult the providers of VisionFS.
>
> Pardon my ignorance, but isn't this the list that deals with gcc as it
> applies to Cygwin? The problem is, by definition, environment-dependant. The
> gcc, cpp and other Cygwin binaries are the "run side" of that environment;
> the "read side" is a common network-drive mapped onto H: (and served by
> VisionFS on the Unix box). If there is better list I'd gladly follow it, but
> starting at gnu.org and going to "Windows->gcc->binaries" leads me back here.
>

As you yourself have said, "The problem is, by definition,
environment-dependant."  No one else has your environment.  You will
have to
debug this yourself, but we'll try to help with suggestions.

Can other programs read the files?  E.G.: `cat /UNIX/foo.h' gives what
results?
Could it be a timing issue, or a permissions issue?  Are you using
Cygwin
symlinks on your H: directory, that most likely won't work unless you
can emulate
the Win32 system file bit on your UNIX server.

Cheers,
Earnie.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
@ 2001-01-03 13:38 M4um
  2001-01-03 14:16 ` Earnie Boyd
  2001-01-03 14:40 ` Larry Hall (RFK Partners, Inc)
  0 siblings, 2 replies; 25+ messages in thread
From: M4um @ 2001-01-03 13:38 UTC (permalink / raw)
  To: cygwin; +Cc: lhall

Larry:

> If you're saying that this problem occurs if you move all the source to a
>  UNIX machine and that the source is local on that machine (i.e. it doesn't
>  somehow involve using the VisionFS file server stuff at all - I have no 
idea  
>  what this does for you), then I would say this is an issue with gcc tools 
>  (well cpp to be exact).  If you only see the problems when using the file 
>  server, then something about that setup/software is probably to blame.  In 
>  the former case, you could send email to the gcc list.  In the latter, you 
>  need to consult the providers of VisionFS.

Pardon my ignorance, but isn't this the list that deals with gcc as it 
applies to Cygwin? The problem is, by definition, environment-dependant. The 
gcc, cpp and other Cygwin binaries are the "run side" of that environment; 
the "read side" is a common network-drive mapped onto H: (and served by 
VisionFS on the Unix box). If there is better list I'd gladly follow it, but 
starting at gnu.org and going to "Windows->gcc->binaries" leads me back here.

That being said, can you suggest a test that would better define exactly 
where the breakdown is occuring?  Remember that we are NOT getting any sort 
of error message: the #included file is being found but not processed.  The 
Unix side of the net has been exhaustively diag'ed and reconfigured in every 
way imaginable, with the same results.  If you'll forgive the term, it 
"smells" like there's a loss of syncronization somewhere in cpp. 

BTW: My arrangement of sources and headers across several different OSs is 
not that unusual. We have C source code for libraries and apps under Unix, 
and are preparing Windows console executables using Cygwin's gcc.  This 
requires that the source code stay on the Unix box and #includes may be found 
on either machine as needed to orient the different compilers to their native 
OS. We will expand this to lynix, etc., as needed across the network, but 
never disturbing the Unix-resident  source.  It's basically using a network 
instead of a cross-compiler.

Thanks,
John

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: #includes not being processed across network (revised)
  2001-01-03 11:11 M4um
@ 2001-01-03 11:54 ` Larry Hall (RFK Partners, Inc)
  0 siblings, 0 replies; 25+ messages in thread
From: Larry Hall (RFK Partners, Inc) @ 2001-01-03 11:54 UTC (permalink / raw)
  To: M4um, cygwin

If you're saying that this problem occurs if you move all the source to a
UNIX machine and that the source is local on that machine (i.e. it doesn't
somehow involve using the VisionFS file server stuff at all - I have no idea 
what this does for you), then I would say this is an issue with gcc tools 
(well cpp to be exact).  If you only see the problems when using the file 
server, then something about that setup/software is probably to blame.  In 
the former case, you could send email to the gcc list.  In the latter, you 
need to consult the providers of VisionFS.

Good luck,

Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



At 02:10 PM 1/3/2001, M4um@aol.com wrote:
>This is a resubmission.  I've completely revised my development platform but 
>still have a problem getting gcc/cpp to properly process #includes across a 
>network.  
>
>The -Idirectory and associated logic for finding the correct header file from 
>a series of search paths is working properly (using output from -dM, 
>-save-temps and -H compiler-switches), but once the header file is identified 
>it is not being processed.  To test this I created a header file with "#error 
>Here Is the Error" as its first line in the Windows #include path and it 
>correctly errored off.  Moving the header file to Unix, the compiler found 
>the file but the #error was not tripped.  In both cases the source code and 
>makefile and all scripts, etc., were resident under Windows.
>
>A related problem: If I move the source code (the .c file) to the UNIX box 
>the same problem is observed with the added confusion that the .i (output 
>from -dM and -H) shows only the first line -- for example, '# 1 "./dcheck.c"' 
>-- and nothing else!   In the previous example it contains processing of all 
>header files, #defines, etc., as it should.
>
>The Unix file server is VisionFS ("VSFU") and I am running the most recent 
>bash, gcc, etc., under Win98 (FAT32)  The server and network have been check 
>out and appear to be working "hot, fast and normal".  I've tried to recreate 
>the problem "by hand" by invoking sh.exe (not bash) directly, cd'ing over to 
>Unix and then doing several instances of "less" on a file in parallel.  The 
>system was able to recognize and warn of locked files when I tried to do 
>multiple editing sessions of a single UNIX file with vi; all permissions are 
>agreeable on both sides of the problem.
>
>Anyone out there have ANY ideas?
>
>John McDonald
>
>
>Here is a portion of the compile stream, captured in situ:
>
>gcc -save-temps -H -dD -g -v -O3 -m486 -I/usr/include -idirafter 
>/cygdrive/h/usr/include  ./dcheck.c -o /usr/bin/dcheck 
>
>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) 
>
>My cygcheck output contains:
>
>Cygnus Win95/NT Configuration Diagnostics
>Current System Time: Wed Jan  3 13:34:09 2001
>
>Win9X Ver 4.10 build 67766222  
>
>Path:   /usr/local/bin
>     /usr/bin
>     /bin
>     /cygdrive/c/WINDOWS
>     /cygdrive/c/WINDOWS/COMMAND
>     /usr/bin
>
>SysDir: C:\WINDOWS\SYSTEM
>WinDir: C:\WINDOWS
>
>PWD = `/cygdrive/d'
>USER = `root'
>MAKE_MODE = `unix'
>HOME = `/cygdrive/d'
>
>PROMPT = `$p$g'
>COMSPEC = `C:\WINDOWS\COMMAND.COM'
>!C: = `C:\WINDOWS'
>CMDLINE = `bash --login -i'
>HOSTNAME = `SEAN'
>!D: = `D:\Cygwin\bin'
>CLASSPATH = `C:\Program Files\PhotoDeluxe 2.0\AdobeConnectables'
>WINDIR = `C:\WINDOWS'
>WINBOOTDIR = `C:\WINDOWS'
>PS1 = `\[\033]0;\007\033[33m\w\033[0m\]# '
>BLASTER = `A220 I5 D1 T4'
>MACHTYPE = `i686-pc-cygwin'
>!H: = `H:\usr\include'
>OLDPWD = `/usr/bin'
>TEMP = `/cygdrive/c/Windows/TEMP'
>SHLVL = `1'
>SHELL = `/bin/sh'
>HOSTTYPE = `i686'
>OSTYPE = `cygwin'
>TERM = `cygwin'
>_ = `/usr/bin/cygcheck'
>TZ = `EST5EDT4,M4.1.0/2,M10.5.0/2'
>
>HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder
>
>\Start Menu\&Programs\Cygnus Solutions
>   (default) = (unsupported type)
>HKEY_CURRENT_USER\Software\Cygnus Solutions
>HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
>HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
>   (default) = `/cygdrive'
>   cygdrive flags = 0x00000020
>HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\08
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\09
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0A
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0B
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0C
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0D
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0E
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0F
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\10
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\11
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\12
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\13
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\14
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\15
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\16
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\17
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\18
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\19
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1A
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1B
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1C
>HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1D
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/
>   (default) = `D:\Cygwin'
>   flags = 0x00000008
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/crc
>   (default) = `D:\Cygwin\usr\crc'
>   flags = 0x00000008
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/UNIX
>   (default) = `H:'
>   flags = 0x0000000a
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
>   (default) = `D:\Cygwin\bin'
>   flags = 0x0000000a
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
>   (default) = `D:\Cygwin\lib'
>   flags = 0x0000000a
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\1.00.000
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\Program Options
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\08
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\09
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0A
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0B
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0C
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0D
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0E
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0F
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\10
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\11
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\12
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\13
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\14
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\15
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\16
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\17
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\18
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\19
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1A
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1B
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1C
>HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1D
>
>a:  fd           N/A    N/A                    
>c:  hd  FAT32   6850Mb  37% CP    UN           WINDOWS98
>d:  hd  FAT32   6169Mb  44% CP    UN           CRC DRIVE
>e:  cd           N/A    N/A                    
>f:  fd           N/A    N/A                    
>g:  cd  CDUDF    657Mb  22% CP    UN           INSTALLSHEI
>h:  net VFSU    3869Mb  40% CP    UN           root
>
>D:\Cygwin\usr\crc  /usr/crc  system  textmode
>D:\Cygwin\bin  /usr/bin  system  binmode
>D:\Cygwin\lib  /usr/lib  system  binmode
>D:\Cygwin  /        system  textmode
>H:    /UNIX    system  binmode
>
>Found: D:\Cygwin\bin\bash.exe
>Found: D:\Cygwin\bin\cat.exe
>Found: D:\Cygwin\bin\cpp.exe
>Found: D:\Cygwin\bin\find.exe
>Found: c:\WINDOWS\COMMAND\find.exe
>Warning: D:\Cygwin\bin\find.exe hides c:\WINDOWS\COMMAND\find.exe
>Found: D:\Cygwin\bin\gcc.exe
>Found: D:\Cygwin\bin\gdb.exe
>Found: D:\Cygwin\bin\ld.exe
>Found: D:\Cygwin\bin\ls.exe
>Found: D:\Cygwin\bin\make.exe
>Found: D:\Cygwin\bin\sh.exe
>Found: \bin\sh.exe
>Warning: D:\Cygwin\bin\sh.exe hides \bin\sh.exe
>(NOTE: BOTH SH.EXE's ARE IDENTICAL)
>
>   115k 1999/09/14 D:\Cygwin\bin\cygitcl30.dll - os=4.0 img=1.0 sys=4.0
>                   "cygitcl30.dll" v0.0 ts=1999/9/13 22:46
>    63k 1999/09/14 D:\Cygwin\bin\cygitk30.dll - os=4.0 img=1.0 sys=4.0
>                   "cygitk30.dll" v0.0 ts=1999/9/13 22:47
>   474k 1999/09/14 D:\Cygwin\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
>                   "cygtcl80.dll" v0.0 ts=1999/9/13 22:31
>    19k 1999/09/14 D:\Cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
>    24k 1999/09/14 D:\Cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
>                   "cygtclreg80.dll" v0.0 ts=1999/9/13 22:31
>   768k 1999/09/14 D:\Cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
>                   "cygtk80.dll" v0.0 ts=1999/9/13 22:36
>   611k 2000/12/25 D:\Cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
>                   "cygwin1.dll" v0.0 ts=2000/12/25 12:39
>     Cygwin DLL version info:
>         dll major: 1001
>         dll minor: 7
>         dll epoch: 19
>         dll bad signal mask: 19005
>         dll old termios: 5
>         dll malloc env: 28
>         api major: 0
>         api minor: 31
>         shared data: 3
>         dll identifier: cygwin1
>         mount registry: 2
>         cygnus registry name: Cygnus Solutions
>         cygwin registry name: Cygwin
>         program options name: Program Options
>         cygwin mount registry name: mounts v2
>         cygdrive flags: cygdrive flags
>         cygdrive prefix: cygdrive prefix
>         cygdrive default prefix: 
>         build date: Mon Dec 25 12:39:48 EST 2000
>         shared id: cygwin1S3
>
>Use -h to see help about each section
>
>
>
>
>--
>Want to unsubscribe from this list?
>Check out: http://cygwin.com/ml/#unsubscribe-simple



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

* #includes not being processed across network (revised)
@ 2001-01-03 11:11 M4um
  2001-01-03 11:54 ` Larry Hall (RFK Partners, Inc)
  0 siblings, 1 reply; 25+ messages in thread
From: M4um @ 2001-01-03 11:11 UTC (permalink / raw)
  To: cygwin

This is a resubmission.  I've completely revised my development platform but 
still have a problem getting gcc/cpp to properly process #includes across a 
network.  

The -Idirectory and associated logic for finding the correct header file from 
a series of search paths is working properly (using output from -dM, 
-save-temps and -H compiler-switches), but once the header file is identified 
it is not being processed.  To test this I created a header file with "#error 
Here Is the Error" as its first line in the Windows #include path and it 
correctly errored off.  Moving the header file to Unix, the compiler found 
the file but the #error was not tripped.  In both cases the source code and 
makefile and all scripts, etc., were resident under Windows.

A related problem: If I move the source code (the .c file) to the UNIX box 
the same problem is observed with the added confusion that the .i (output 
from -dM and -H) shows only the first line -- for example, '# 1 "./dcheck.c"' 
-- and nothing else!   In the previous example it contains processing of all 
header files, #defines, etc., as it should.

The Unix file server is VisionFS ("VSFU") and I am running the most recent 
bash, gcc, etc., under Win98 (FAT32)  The server and network have been check 
out and appear to be working "hot, fast and normal".  I've tried to recreate 
the problem "by hand" by invoking sh.exe (not bash) directly, cd'ing over to 
Unix and then doing several instances of "less" on a file in parallel.  The 
system was able to recognize and warn of locked files when I tried to do 
multiple editing sessions of a single UNIX file with vi; all permissions are 
agreeable on both sides of the problem.

Anyone out there have ANY ideas?

John McDonald


Here is a portion of the compile stream, captured in situ:

gcc -save-temps -H -dD -g -v -O3 -m486 -I/usr/include -idirafter 
/cygdrive/h/usr/include  ./dcheck.c -o /usr/bin/dcheck 

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) 

My cygcheck output contains:

Cygnus Win95/NT Configuration Diagnostics
Current System Time: Wed Jan  3 13:34:09 2001

Win9X Ver 4.10 build 67766222  

Path:   /usr/local/bin
    /usr/bin
    /bin
    /cygdrive/c/WINDOWS
    /cygdrive/c/WINDOWS/COMMAND
    /usr/bin

SysDir: C:\WINDOWS\SYSTEM
WinDir: C:\WINDOWS

PWD = `/cygdrive/d'
USER = `root'
MAKE_MODE = `unix'
HOME = `/cygdrive/d'

PROMPT = `$p$g'
COMSPEC = `C:\WINDOWS\COMMAND.COM'
!C: = `C:\WINDOWS'
CMDLINE = `bash --login -i'
HOSTNAME = `SEAN'
!D: = `D:\Cygwin\bin'
CLASSPATH = `C:\Program Files\PhotoDeluxe 2.0\AdobeConnectables'
WINDIR = `C:\WINDOWS'
WINBOOTDIR = `C:\WINDOWS'
PS1 = `\[\033]0;\007\033[33m\w\033[0m\]# '
BLASTER = `A220 I5 D1 T4'
MACHTYPE = `i686-pc-cygwin'
!H: = `H:\usr\include'
OLDPWD = `/usr/bin'
TEMP = `/cygdrive/c/Windows/TEMP'
SHLVL = `1'
SHELL = `/bin/sh'
HOSTTYPE = `i686'
OSTYPE = `cygwin'
TERM = `cygwin'
_ = `/usr/bin/cygcheck'
TZ = `EST5EDT4,M4.1.0/2,M10.5.0/2'

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder

\Start Menu\&Programs\Cygnus Solutions
  (default) = (unsupported type)
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x00000020
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\08
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\09
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0A
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0B
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0C
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0D
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0E
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0F
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\10
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\11
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\12
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\13
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\14
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\15
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\16
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\17
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\18
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\19
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1A
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1B
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1C
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1D
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `D:\Cygwin'
  flags = 0x00000008
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/crc
  (default) = `D:\Cygwin\usr\crc'
  flags = 0x00000008
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/UNIX
  (default) = `H:'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `D:\Cygwin\bin'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `D:\Cygwin\lib'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\1.00.000
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\08
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\09
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0A
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0B
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0C
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0D
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0E
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0F
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\10
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\11
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\12
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\13
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\14
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\15
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\16
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\17
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\18
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\19
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1A
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1B
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1C
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1D

a:  fd           N/A    N/A                    
c:  hd  FAT32   6850Mb  37% CP    UN           WINDOWS98
d:  hd  FAT32   6169Mb  44% CP    UN           CRC DRIVE
e:  cd           N/A    N/A                    
f:  fd           N/A    N/A                    
g:  cd  CDUDF    657Mb  22% CP    UN           INSTALLSHEI
h:  net VFSU    3869Mb  40% CP    UN           root

D:\Cygwin\usr\crc  /usr/crc  system  textmode
D:\Cygwin\bin  /usr/bin  system  binmode
D:\Cygwin\lib  /usr/lib  system  binmode
D:\Cygwin  /        system  textmode
H:    /UNIX    system  binmode

Found: D:\Cygwin\bin\bash.exe
Found: D:\Cygwin\bin\cat.exe
Found: D:\Cygwin\bin\cpp.exe
Found: D:\Cygwin\bin\find.exe
Found: c:\WINDOWS\COMMAND\find.exe
Warning: D:\Cygwin\bin\find.exe hides c:\WINDOWS\COMMAND\find.exe
Found: D:\Cygwin\bin\gcc.exe
Found: D:\Cygwin\bin\gdb.exe
Found: D:\Cygwin\bin\ld.exe
Found: D:\Cygwin\bin\ls.exe
Found: D:\Cygwin\bin\make.exe
Found: D:\Cygwin\bin\sh.exe
Found: \bin\sh.exe
Warning: D:\Cygwin\bin\sh.exe hides \bin\sh.exe
(NOTE: BOTH SH.EXE's ARE IDENTICAL)

  115k 1999/09/14 D:\Cygwin\bin\cygitcl30.dll - os=4.0 img=1.0 sys=4.0
                  "cygitcl30.dll" v0.0 ts=1999/9/13 22:46
   63k 1999/09/14 D:\Cygwin\bin\cygitk30.dll - os=4.0 img=1.0 sys=4.0
                  "cygitk30.dll" v0.0 ts=1999/9/13 22:47
  474k 1999/09/14 D:\Cygwin\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtcl80.dll" v0.0 ts=1999/9/13 22:31
   19k 1999/09/14 D:\Cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
   24k 1999/09/14 D:\Cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtclreg80.dll" v0.0 ts=1999/9/13 22:31
  768k 1999/09/14 D:\Cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtk80.dll" v0.0 ts=1999/9/13 22:36
  611k 2000/12/25 D:\Cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=2000/12/25 12:39
    Cygwin DLL version info:
        dll major: 1001
        dll minor: 7
        dll epoch: 19
        dll bad signal mask: 19005
        dll old termios: 5
        dll malloc env: 28
        api major: 0
        api minor: 31
        shared data: 3
        dll identifier: cygwin1
        mount registry: 2
        cygnus registry name: Cygnus Solutions
        cygwin registry name: Cygwin
        program options name: Program Options
        cygwin mount registry name: mounts v2
        cygdrive flags: cygdrive flags
        cygdrive prefix: cygdrive prefix
        cygdrive default prefix: 
        build date: Mon Dec 25 12:39:48 EST 2000
        shared id: cygwin1S3

Use -h to see help about each section




--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2001-01-08  8:17 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-01-05  7:20 #includes not being processed across network (revised) M4um
2001-01-05  7:41 ` Larry Hall (RFK Partners, Inc)
2001-01-05  8:01   ` Markus Hoenicka
2001-01-05  8:26     ` Larry Hall (RFK Partners, Inc)
2001-01-05  8:42       ` Ray Easton
2001-01-05  8:52         ` Larry Hall (RFK Partners, Inc)
  -- strict thread matches above, loose matches on Subject: below --
2001-01-08  8:17 M4um
2001-01-04 12:49 M4um
2001-01-04 12:56 ` Christopher Faylor
2001-01-04  8:24 M4um
2001-01-04  9:38 ` Earnie Boyd
2001-01-04  6:36 M4um
2001-01-04  6:49 ` Earnie Boyd
2001-01-04  5:29 M4um
2001-01-04  6:24 ` Earnie Boyd
2001-01-04  6:27   ` Robert Collins
2001-01-04  6:39     ` Earnie Boyd
2001-01-03 18:35 M4um
2001-01-04  7:40 ` Larry Hall (RFK Partners, Inc)
2001-01-03 18:32 M4um
2001-01-03 13:38 M4um
2001-01-03 14:16 ` Earnie Boyd
2001-01-03 14:40 ` Larry Hall (RFK Partners, Inc)
2001-01-03 11:11 M4um
2001-01-03 11:54 ` Larry Hall (RFK Partners, Inc)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).