* 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 12:49 #includes not being processed across network (revised) 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-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-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-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: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 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 7:20 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: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-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-04 12:49 #includes not being processed across network (revised) M4um
2001-01-04 12:56 ` Christopher Faylor
-- strict thread matches above, loose matches on Subject: below --
2001-01-08 8:17 M4um
2001-01-05 7:20 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)
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).