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
