public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Empty include file on samba share
@ 2009-01-07 17:23 Fabian Cenedese
  2009-01-07 18:05 ` Larry Hall (Cygwin)
       [not found] ` <4966299F.9040300@cygwin.com>
  0 siblings, 2 replies; 8+ messages in thread
From: Fabian Cenedese @ 2009-01-07 17:23 UTC (permalink / raw)
  To: cygwin

Hi

I have a problem that may be cygwin or not. I'll just ask here if anybody knows
something (or to show me some better place to go to).

We use a quite old cross-gcc (2.95.2), built with cygwin and running on various
windows (since NT on to vista). The currently used cygwin is version
1.5.19-cr-0x5ef, but we have also worked with other versions. We have
some projects that are C++ with header files and can be compiled with
no problems on a local drive.

However if the whole C++ project is moved from the local drive to a
share (samba, probably also windows) the compilation may fail with
various errors. The main problem seems to be that include files are not
read properly. They are found (gcc emits an error if the name is wrong)
but the content seems not to be read. Even if such a problematic
header file contains crap it is not mentioned by gcc. To make things
worse is that on different computers the compilation may fail differently
or even work without problems.

I don't know if there's anything I could change in cygwin to improve
this (except updating, but I'd like to hear first, if this is known).

Has anybody ever experienced something similar? Or an idea what I
could look into (from the cygwin side)? I have already asked on the
gcc mailinglist, but it was unknown so far.

Thanks for any help

bye  Fabi


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

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

* Re: Empty include file on samba share
  2009-01-07 17:23 Empty include file on samba share Fabian Cenedese
@ 2009-01-07 18:05 ` Larry Hall (Cygwin)
  2009-01-08 10:33   ` Fabian Cenedese
       [not found]   ` <2ca21dcc0901091134l682660fem1ebac27ee6afd69e@mail.gmail.co  m>
       [not found] ` <4966299F.9040300@cygwin.com>
  1 sibling, 2 replies; 8+ messages in thread
From: Larry Hall (Cygwin) @ 2009-01-07 18:05 UTC (permalink / raw)
  To: cygwin

Fabian Cenedese wrote:
> Hi
> 
> I have a problem that may be cygwin or not. I'll just ask here if anybody knows
> something (or to show me some better place to go to).
> 
> We use a quite old cross-gcc (2.95.2), built with cygwin and running on various
> windows (since NT on to vista). The currently used cygwin is version
> 1.5.19-cr-0x5ef, but we have also worked with other versions. We have
> some projects that are C++ with header files and can be compiled with
> no problems on a local drive.
> 
> However if the whole C++ project is moved from the local drive to a
> share (samba, probably also windows) the compilation may fail with
> various errors. The main problem seems to be that include files are not
> read properly. They are found (gcc emits an error if the name is wrong)
> but the content seems not to be read. Even if such a problematic
> header file contains crap it is not mentioned by gcc. To make things
> worse is that on different computers the compilation may fail differently
> or even work without problems.
> 
> I don't know if there's anything I could change in cygwin to improve
> this (except updating, but I'd like to hear first, if this is known).
> 
> Has anybody ever experienced something similar? Or an idea what I
> could look into (from the cygwin side)? I have already asked on the
> gcc mailinglist, but it was unknown so far.

We're missing some information about your system configuration.  Please
read the problem reporting guidelines found at the link below, paying
particular attention to the part about the cygcheck output.  A STC might
also be warranted.

> Problem reports:       http://cygwin.com/problems.html

Absent the above, my WAG is that you need to add 'smbntsec' to your
CYGWIN environment variable.

<http://cygwin.com/cygwin-ug-net/using-cygwinenv.html>

Exit all Cygwin processes/services for good measure.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

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

* Re: Empty include file on samba share
  2009-01-07 18:05 ` Larry Hall (Cygwin)
@ 2009-01-08 10:33   ` Fabian Cenedese
  2009-01-09 20:49     ` Dave Korn
       [not found]   ` <2ca21dcc0901091134l682660fem1ebac27ee6afd69e@mail.gmail.co  m>
  1 sibling, 1 reply; 8+ messages in thread
From: Fabian Cenedese @ 2009-01-08 10:33 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]

At 12:22 07.01.2009 -0500, Larry Hall (Cygwin) wrote:
>Fabian Cenedese wrote:
>>However if the whole C++ project is moved from the local drive to a
>>share (samba, probably also windows) the compilation may fail with
>>various errors. The main problem seems to be that include files are not
>>read properly. They are found (gcc emits an error if the name is wrong)
>>but the content seems not to be read. Even if such a problematic
>>header file contains crap it is not mentioned by gcc. To make things
>>worse is that on different computers the compilation may fail differently
>>or even work without problems.
>
>We're missing some information about your system configuration.  Please
>read the problem reporting guidelines found at the link below, paying
>particular attention to the part about the cygcheck output.  A STC might
>also be warranted.

The output is attached. But the cygwin tool list is not important as we only
provide the minimum (meaning cygwin1.dll) to run the compiler and linker.
Drive q is a samba share, not really NTFS.

If STC means 'simple test case' then I can't provide one as it doesn't happen
reproducably on my computer, not to mention on other's computers. The
case itself is simple: call gcc to compile a file that lies on a share (as well
as the needed project includes). The c library includes are still local (N:).

make: Entering directory `Q:/Machine/Control'
gcc.exe -mcpu=603 -c -g -fno-exceptions -fno-rtti -Wall -Wconversion -Wsign-compare -O2 -fverbose-asm \
        -S \
        -IN:/IMD/Include32 -IQ:/Machine/Control/firmware/info_ppc/inc -IQ:/Machine/Control/firmware/info_ppc/hal -IQ:/Machine/Control/os/inos/inc -IQ:/Machine/Control/os/inco/inc -IQ:/Machine/Control/os/inos/hal -IQ:/Machine/Control/application/syscalls/include -IQ:/Machine/Control/application/handling/include -IQ:/Machine/Control/application/axes/include -IQ:/Machine/Control/application/syscalls/hal -IQ:/Machine/Common/include \
        -DPPC603 -DINFO_SAM -DINOS_OLD_BITS -D_DEBUG -DINOS_NG -DINOS_LIBC_REENTRANCY_SUPPORT \
        Q:/Machine/Control/Application/Axes/Source/CAxis.cpp -o Q:/Machine/Control/bin32/CAxis.s
In file included from Q:/Machine/Control/os/inos/inc/CINOSProcessImage.h:194,
                 from Q:/Machine/Control/firmware/info_ppc/inc/info_acs.h:198,
                 from /cygdrive/c/Temp/cc30zQvv.ii:49:
Q:/Machine/Control/os/inos/inc/CINOSAdcChannel.h:54: parse error before `{'
...
And many other errors coming from unknown items because of seemingly not
or badly read include files.

However the same line works fine if the project lies on a local drive.

>>Problem reports:       http://cygwin.com/problems.html
>
>Absent the above, my WAG is that you need to add 'smbntsec' to your
>CYGWIN environment variable.

If I add this environment variable with smbntsec I can't even start
compiling anymore:

gcc: Q:\Machine\Control\Application\Axes\Source\CAxis.cpp: Permission denied
gcc: No input files

But I have no problem viewing this file or any other from the project
in a windows editor. Using ntsec or nothing at all I'm back to my
original problem.

Thanks

bye  Fabi

[-- Attachment #2: cygcheck.out --]
[-- Type: text/plain, Size: 8727 bytes --]


Cygwin Configuration Diagnostics
Current System Time: Thu Jan 08 08:53:42 2009

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:	C:\WINDOWS\system32
	C:\WINDOWS
	C:\WINDOWS\System32\Wbem
	N:\IMD\Bin
	x:\indel\bin
	x:\indel\lib
	c:\python24
	C:\PROGRA~1\MICROS~2\Office
	C:\Programme\Rat\common
	C:\Programme\Gemeinsame Dateien\Compuware
	C:\Programme\Gemeinsame Dateien\Compuware\
	C:\Programme\QuickTime\QTSystem\
	C:\Programme\Gemeinsame Dateien\GTK\2.0\bin
	C:\Programme\Visual Leak Detector\bin
	C:\programme\rtksupport
	C:\Programme\TortoiseSVN\bin
	C:\Programme\Microsoft Visual Studio\Common\Tools\WinNT
	C:\Programme\Microsoft Visual Studio\Common\MSDev98\Bin
	C:\Programme\Microsoft Visual Studio\Common\Tools
	C:\Programme\Microsoft Visual Studio\VC98\bin

Output from i:\cyghome\bin\id.exe (nontsec)
UID: 11119(FABI)        GID: 10545(mkgroup-l-d)
=0(root)                513(Kein)               544(Administratoren)
545(Benutzer)           10545(mkgroup-l-d)

Output from i:\cyghome\bin\id.exe (ntsec)
UID: 11119(FABI)        GID: 10545(mkgroup-l-d)
=0(root)                513(Kein)               544(Administratoren)
545(Benutzer)           10545(mkgroup-l-d)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

Path = 'C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;N:\IMD\Bin;x:\indel\bin;x:\indel\lib;c:\python24;C:\PROGRA~1\MICROS~2\Office;C:\Programme\Rat\common;C:\Programme\Gemeinsame Dateien\Compuware;C:\Programme\Gemeinsame Dateien\Compuware\;C:\Programme\QuickTime\QTSystem\;C:\Programme\Gemeinsame Dateien\GTK\2.0\bin;C:\Programme\Visual Leak Detector\bin;C:\programme\rtksupport;C:\Programme\TortoiseSVN\bin;C:\Programme\Microsoft Visual Studio\Common\Tools\WinNT;C:\Programme\Microsoft Visual Studio\Common\MSDev98\Bin;C:\Programme\Microsoft Visual Studio\Common\Tools;C:\Programme\Microsoft Visual Studio\VC98\bin'

ALLUSERSPROFILE = 'C:\Dokumente und Einstellungen\All Users'
APPDATA = 'C:\Dokumente und Einstellungen\Fabi\Anwendungsdaten'
CLASSPATH = '.;C:\Programme\Gemeinsame Dateien\Compuware;C:\Programme\Java\jre1.6.0_01\lib\ext\QTJava.zip'
CLIENTNAME = 'Console'
CommonProgramFiles = 'C:\Programme\Gemeinsame Dateien'
COMPUTERNAME = 'PCFABI'
ComSpec = 'C:\WINDOWS\system32\cmd.exe'
FP_NO_HOST_CHECK = 'NO'
HOMEDRIVE = 'C:'
HOMEPATH = '\Dokumente und Einstellungen\Fabi'
IMD_PATH = 'N:\IMD'
include = 'C:\Programme\Microsoft Visual Studio\VC98\atl\include;C:\Programme\Microsoft Visual Studio\VC98\mfc\include;C:\Programme\Microsoft Visual Studio\VC98\include'
INDEL_ROOT = 'x:\indel'
LANG = 'de'
lib = 'C:\Programme\Microsoft Visual Studio\VC98\mfc\lib;C:\Programme\Microsoft Visual Studio\VC98\lib'
LOGONSERVER = '\\PCFABI'
MSDevDir = 'C:\Programme\Microsoft Visual Studio\Common\MSDev98'
NTRESKIT = 'C:\programme\rtksupport'
NUMBER_OF_PROCESSORS = '2'
OS = 'Windows_NT'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = 'x86'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 15 Stepping 6, GenuineIntel'
PROCESSOR_LEVEL = '6'
PROCESSOR_REVISION = '0f06'
ProgramFiles = 'C:\Programme'
PROMPT = '$P$G'
QTJAVA = 'C:\Programme\Java\jre1.6.0_01\lib\ext\QTJava.zip'
SESSIONNAME = 'Console'
SystemDrive = 'C:'
SystemRoot = 'C:\WINDOWS'
TEMP = 'C:\Temp'
TMP = 'C:\Temp'
USERDOMAIN = 'PCFABI'
USERNAME = 'Fabi'
USERPROFILE = 'C:\Dokumente und Einstellungen\Fabi'
windir = 'C:\WINDOWS'
POSIXLY_CORRECT = '1'

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 = 0x00000022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x00000022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 'i:\cyghome'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = 'i:\cyghome/bin'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = 'i:\cyghome/lib'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

a:  fd             N/A    N/A                    
c:  hd  NTFS     20002Mb  67% CP CS UN PA FC     SYSTEM
i:  hd  NTFS    109999Mb  81% CP CS UN PA FC     APPS
n:  hd  NTFS    239359Mb  93% CP CS UN PA FC     PROJECTS
q:  net NTFS   3687507Mb  45% CP CS    PA        PUBLIC
r:  cd             N/A    N/A                    
x:  hd  NTFS    109999Mb  81% CP CS UN PA FC     APPS
z:  hd  NTFS      9773Mb  77% CP CS UN PA FC     BACKUP

.               /cygdrive  user    binmode,cygdrive
i:\cyghome      /          system  binmode
i:\cyghome/bin  /usr/bin   system  binmode
i:\cyghome/lib  /usr/lib   system  binmode
.               /cygdrive  system  binmode,cygdrive

Not Found: awk
Not Found: bash
Not Found: cat
Not Found: cp
Not Found: cpp (good!)
Not Found: crontab
Not Found: find
Not Found: gcc
Not Found: gdb
Not Found: grep
Found: C:\programme\rtksupport\kill.exe
Not Found: ld
Not Found: ls
Found: N:\IMD\Bin\make.exe
Not Found: mv
Not Found: patch
Not Found: perl
Not Found: rm
Not Found: sed
Not Found: ssh
Found: N:\IMD\Bin\sh.exe
Not Found: tar
Found: N:\IMD\Bin\test.exe
Not Found: vi
Not Found: vim

 1763k 2006/07/14 N:\IMD\Bin\Gnu32\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=2006/1/20 19:28
    Cygwin DLL version info:
        DLL version: 1.5.19
        DLL epoch: 19
        DLL bad signal mask: 19005
        DLL old termios: 5
        DLL malloc env: 28
        API major: 0
        API minor: 150
        Shared data: 4
        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: Fri Jan 20 13:28:43 EST 2006
        CVS tag: cr-0x5ef
        Shared id: cygwin1S4


Can't find the cygrunsrv utility, skipping services check.


Cygwin Package Information
Last downloaded files to: L:\cygwin_31_mar_06\ftp%3a%2f%2fmirror.switch.ch%2fmirror%2fcygwin
Last downloaded files from: L:\cygwin_31_mar_06\ftp%3a%2f%2fmirror.switch.ch%2fmirror%2fcygwin

Package              Version
_update-info-dir     00385-1
alternatives         1.3.20a-2
ash                  20040127-3
autoconf             2.59-2
autoconf2.1          2.13-1
autoconf2.5          2.59-2
automake1.9          1.9.6-1
base-files           3.7-1
base-passwd          2.2-1
bash                 3.0-14
binutils             20050610-1
bison                2.1-1
bzip2                1.0.3-1
coreutils            5.94-1
crypt                1.1-1
cvs                  1.11.17-1
cygutils             1.2.10-1
cygwin               1.5.19-4
cygwin-doc           1.4-3
diffutils            2.8.7-1
editrights           1.01-1
expat                1.95.8-1
findutils            4.2.27-1
gawk                 3.1.5-3
gcc                  3.4.4-1
gcc-core             3.4.4-1
gcc-g++              3.4.4-1
gcc-mingw-core       20050522-1
gcc-mingw-g++        20050522-1
gdbm                 1.8.3-7
grep                 2.5.1a-2
groff                1.18.1-2
gzip                 1.3.5-1
less                 381-1
libbz2_1             1.0.3-1
libcharset1          1.9.2-2
libdb4.2             4.2.52-1
libdb4.3             4.3.28-1
libgdbm              1.8.0-5
libgdbm-devel        1.8.3-7
libgdbm3             1.8.3-3
libgdbm4             1.8.3-7
libiconv             1.9.2-2
libiconv2            1.9.2-2
libintl              0.10.38-3
libintl1             0.10.40-1
libintl2             0.12.1-3
libintl3             0.14.5-1
libncurses5          5.2-1
libncurses6          5.2-8
libncurses7          5.3-4
libncurses8          5.5-2
libpcre0             6.3-1
libpopt0             1.6.4-4
libreadline4         4.1-2
libreadline5         4.3-5
libreadline6         5.1-5
login                1.9-7
m4                   1.4.4-1
make                 3.80-1
man                  1.5p-1
mingw-runtime        3.9-2
mktemp               1.5-3
ncurses              5.5-2
perl                 5.8.7-5
run                  1.1.7-1
sed                  4.1.5-1
tar                  1.15.1-4
termcap              20050421-1
terminfo             5.5_20060323-1
texinfo              4.8-1
w32api               3.6-1
which                1.7-1
zlib                 1.2.3-1
Use -h to see help about each section


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

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

* Re: Empty include file on samba share
       [not found] ` <4966299F.9040300@cygwin.com>
@ 2009-01-09 12:21   ` Fabian Cenedese
  2009-01-09 17:55     ` Larry Hall (Cygwin)
  0 siblings, 1 reply; 8+ messages in thread
From: Fabian Cenedese @ 2009-01-09 12:21 UTC (permalink / raw)
  To: cygwin

At 11:28 08.01.2009 -0500, Larry Hall (Cygwin) wrote:
>Fabian Cenedese wrote:
>>At 12:22 07.01.2009 -0500, Larry Hall (Cygwin) wrote:
>>>Fabian Cenedese wrote:
>>>>However if the whole C++ project is moved from the local drive to a
>>>>share (samba, probably also windows) the compilation may fail with
>>>>various errors. The main problem seems to be that include files are not
>>>>read properly. They are found (gcc emits an error if the name is wrong)
>>>>but the content seems not to be read. Even if such a problematic
>>>>header file contains crap it is not mentioned by gcc. To make things
>>>>worse is that on different computers the compilation may fail differently
>>>>or even work without problems.
>>>We're missing some information about your system configuration.  Please
>>>read the problem reporting guidelines found at the link below, paying
>>>particular attention to the part about the cygcheck output.  A STC might
>>>also be warranted.
>>The output is attached. But the cygwin tool list is not important as we only
>>provide the minimum (meaning cygwin1.dll) to run the compiler and linker.
>>Drive q is a samba share, not really NTFS.
>
>ATM, I have only a few comments:
>
>1. Your installation is outdated.  You may have better luck if you upgrade.

I might try that, but I guess I need to rebuild the tools to use 1.7.
I have now used gcc 3.4.3. and 4.1. with exactly the same cygwin1.dll.
They both could compile without showing these errors. So I guess 
cygwin is not at fault.

>2. You seem to have competing tools installed and to not have Cygwin tools
>   in your path.  These two things make it unclear what parts of Cygwin
>   are actually in use in your scenario.

Why do you say competing tools? There's only 1 cygwin1.dll in the path.
And the other cygwin tools are not needed. gcc, as, ld etc are all in the
same directory, built with the same environment.

>3. Since you mention your share is just a "samba share", I'm not sure if
>   you mean it's from a Linux machine or simply a Windows server with a
>   FAT* partition.  If the former, have you tried using NFS?

Yes, it's a linux file server with samba shares, underlying FS probably ext3.
I have not tried NFS as we mostly use windows and we have customer
reports with the same problem that only use windows (no linux server).

>4. Are you sure there aren't network issues here?

Do you mean IP-address conflicts? Or what else? As the windows network
doesn't show problems the basic setup seems fine.

Thanks for the help, I'll start looking into gcc changes.

bye  Fabi


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

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

* Re: Empty include file on samba share
  2009-01-09 12:21   ` Fabian Cenedese
@ 2009-01-09 17:55     ` Larry Hall (Cygwin)
  0 siblings, 0 replies; 8+ messages in thread
From: Larry Hall (Cygwin) @ 2009-01-09 17:55 UTC (permalink / raw)
  To: cygwin

Fabian Cenedese wrote:
> At 11:28 08.01.2009 -0500, Larry Hall (Cygwin) wrote:

<snip>

>> 1. Your installation is outdated.  You may have better luck if you upgrade.
> 
> I might try that, but I guess I need to rebuild the tools to use 1.7.
> I have now used gcc 3.4.3. and 4.1. with exactly the same cygwin1.dll.
> They both could compile without showing these errors. So I guess 
> cygwin is not at fault.

OK, good to know.

>> 2. You seem to have competing tools installed and to not have Cygwin tools
>>   in your path.  These two things make it unclear what parts of Cygwin
>>   are actually in use in your scenario.
> 
> Why do you say competing tools? There's only 1 cygwin1.dll in the path.
> And the other cygwin tools are not needed. gcc, as, ld etc are all in the
> same directory, built with the same environment.

Your installation is grabbing tools from 'C:\programme\rtksupport\' and
'N:\IMD\Bin\'.  These match Cygwin counterparts but aren't overridden by
the Cygwin tools in your environment.  This can lead to strange failures
if these different sets of tools with different requirements interact.

>> 3. Since you mention your share is just a "samba share", I'm not sure if
>>   you mean it's from a Linux machine or simply a Windows server with a
>>   FAT* partition.  If the former, have you tried using NFS?
> 
> Yes, it's a linux file server with samba shares, underlying FS probably ext3.
> I have not tried NFS as we mostly use windows and we have customer
> reports with the same problem that only use windows (no linux server).

Perhaps 'smbntsec' would be a help there, though it may only be useful
if it is set prior to unpacking stuff into those remote locations (or
if unpacked on that system locally under Cygwin, you may need to make
sure you have that user in your '/etc/passwd' and/or set the POSIX
permissions appropriately.)

>> 4. Are you sure there aren't network issues here?
> 
> Do you mean IP-address conflicts? Or what else? As the windows network
> doesn't show problems the basic setup seems fine.

I mean anything that could cause sporadic, intermittent drop-outs.  This
could certainly explain why sometimes it works and sometimes it doesn't.

> Thanks for the help, I'll start looking into gcc changes.

Does sound the most promising, though it's not clear to me why gcc would
be having problems here.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

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

* Re: Empty include file on samba share
  2009-01-08 10:33   ` Fabian Cenedese
@ 2009-01-09 20:49     ` Dave Korn
  0 siblings, 0 replies; 8+ messages in thread
From: Dave Korn @ 2009-01-09 20:49 UTC (permalink / raw)
  To: cygwin

Fabian Cenedese wrote:

> make: Entering directory `Q:/Machine/Control'
> gcc.exe -mcpu=603 -c -g -fno-exceptions -fno-rtti -Wall -Wconversion -Wsign-compare -O2 -fverbose-asm \
>         -S \
>         -IN:/IMD/Include32 -IQ:/Machine/Control/firmware/info_ppc/inc -IQ:/Machine/Control/firmware/info_ppc/hal -IQ:/Machine/Control/os/inos/inc -IQ:/Machine/Control/os/inco/inc -IQ:/Machine/Control/os/inos/hal -IQ:/Machine/Control/application/syscalls/include -IQ:/Machine/Control/application/handling/include -IQ:/Machine/Control/application/axes/include -IQ:/Machine/Control/application/syscalls/hal -IQ:/Machine/Common/include \
>         -DPPC603 -DINFO_SAM -DINOS_OLD_BITS -D_DEBUG -DINOS_NG -DINOS_LIBC_REENTRANCY_SUPPORT \
>         Q:/Machine/Control/Application/Axes/Source/CAxis.cpp -o Q:/Machine/Control/bin32/CAxis.s
> In file included from Q:/Machine/Control/os/inos/inc/CINOSProcessImage.h:194,
>                  from Q:/Machine/Control/firmware/info_ppc/inc/info_acs.h:198,
>                  from /cygdrive/c/Temp/cc30zQvv.ii:49:
> Q:/Machine/Control/os/inos/inc/CINOSAdcChannel.h:54: parse error before `{'
> ...
> And many other errors coming from unknown items because of seemingly not
> or badly read include files.
>
> However the same line works fine if the project lies on a local drive.

  Have you tried adding "--save-temps" to your CFLAGS so that you can capture
the pre-processor output and take a look at the corruption?  It might just
give us a clue.

    cheers,
      DaveK

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

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

* Re: Empty include file on samba share
       [not found]   ` <2ca21dcc0901091134l682660fem1ebac27ee6afd69e@mail.gmail.co  m>
@ 2009-01-16 12:24     ` Fabian Cenedese
  2010-03-17  8:19     ` Fabian Cenedese
  1 sibling, 0 replies; 8+ messages in thread
From: Fabian Cenedese @ 2009-01-16 12:24 UTC (permalink / raw)
  To: cygwin

At 19:34 09.01.2009 +0000, Dave Korn wrote:
>  Have you tried adding "--save-temps" to your CFLAGS so that you can capture
>the pre-processor output and take a look at the corruption?  It might just
>give us a clue.

I have tried a different file and will show the include structure as well as the output.
This is with gcc 2.95.2.

CTaskTemplateClass.cpp
#include <inos.h>
        #include <inos_mod.h>
                #include <inos_typ.h>
                        various typedefs that show up in both outputs.

                        #include <fixed32.h>
                                class definition shows up in both outputs.
                        #include <fixed64.h>
                                include and class definition completely missing if on share

                        various typedefs that show up in both outputs.
---snipped---
#include <CINOSMemoryHeap.h>
#include <CINOSMemoryPool.h>
        include and class definition completely missing if on share
#include <CINOSPartitionMemory.h>
---snipped---


The relevant parts are quoted here:

---------- Local drive ----------
# 1 "N:/Indel-PPC/Tests/sharetest/os/inos/inc/fixed32.h" 1
---snipped---
                int32 m_iData;
}; // end of fixed32 class definition

# 113 "N:/Indel-PPC/Tests/sharetest/os/inos/inc/inos_typ.h" 2

# 1 "N:/Indel-PPC/Tests/sharetest/os/inos/inc/fixed64.h" 1
 
class fixed64
---snipped---
};
 
# 114 "N:/Indel-PPC/Tests/sharetest/os/inos/inc/inos_typ.h" 2

typedef struct _INOSTime {
---------- End local drive ----------



---------- Shared drive ----------
# 1 "G:/Fabi/sharetest/os/inos/inc/fixed32.h" 1
---snipped---
                int32 m_iData;
}; // end of fixed32 class definition
 
# 113 "G:/Fabi/sharetest/os/inos/inc/inos_typ.h" 2

typedef struct _INOSTime {
----- End shared drive -----


The rest of the outputs is identical except the different paths and the missing
includes. For some reason some include statements are completely skipped.
Adding a newline or a comment between the includes didn't help, neither did
adding a newline to the end of fixed32.h or fixed64.h. The fixed64 type was
always unknown in the further compilation.

Using gcc 4.1.0 the compilation worked correctly with exactly the same files:

  int32 m_iData;
};
# 114 "G:/Fabi/sharetest/os/inos/inc/inos_typ.h" 2
# 1 "G:/Fabi/sharetest/os/inos/inc/fixed64.h" 1
# 81 "G:/Fabi/sharetest/os/inos/inc/fixed64.h"
class fixed64


I don't know if this is of any help except that the error seems to be in gcc 2.95
and that I could start looking into gcc sources for changes.

Thanks

bye  Fabi


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

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

* Re: Empty include file on samba share
       [not found]   ` <2ca21dcc0901091134l682660fem1ebac27ee6afd69e@mail.gmail.co  m>
  2009-01-16 12:24     ` Fabian Cenedese
@ 2010-03-17  8:19     ` Fabian Cenedese
  1 sibling, 0 replies; 8+ messages in thread
From: Fabian Cenedese @ 2010-03-17  8:19 UTC (permalink / raw)
  To: cygwin


>> And many other errors coming from unknown items because of seemingly not
>> or badly read include files.
>>
>> However the same line works fine if the project lies on a local drive.
>
>  Have you tried adding "--save-temps" to your CFLAGS so that you can capture
>the pre-processor output and take a look at the corruption?  It might just
>give us a clue.

I'm reviving this old thread in case somebody is looking for a solution.

cpp.exe has a mechanism to ensure that the same file will not be included
multiple times. It identifies "the same file" by remembering the device-id
and inode-number of each already included file. Unfortunately, when the
above problem happens, the inode numbers of different files are equal!
That's why cpp.exe did just not include the second file and also didn't
report any error...

The issue about the non-unique inode numbers is described here:
http://www.cygwin.com/cygwin-ug-net/highlights.html

"On file systems which don't support unique persistent file IDs (FAT, older Samba shares) the inode number for a file is calculated by hashing its full Win32 path. The inode number generated by the stat call always matches the one returned in d_ino of the dirent structure. It is worth noting that the number produced by this method is not guaranteed to be unique. However, we have not found this to be a significant problem because of the low probability of generating a duplicate inode number."

As gcc 3 and 4 don't have this problem they may do additional or
different checks to not include a file twice.

bye  Fabi


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

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

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

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-01-07 17:23 Empty include file on samba share Fabian Cenedese
2009-01-07 18:05 ` Larry Hall (Cygwin)
2009-01-08 10:33   ` Fabian Cenedese
2009-01-09 20:49     ` Dave Korn
     [not found]   ` <2ca21dcc0901091134l682660fem1ebac27ee6afd69e@mail.gmail.co  m>
2009-01-16 12:24     ` Fabian Cenedese
2010-03-17  8:19     ` Fabian Cenedese
     [not found] ` <4966299F.9040300@cygwin.com>
2009-01-09 12:21   ` Fabian Cenedese
2009-01-09 17:55     ` Larry Hall (Cygwin)

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