Problems with path resolution

Problems with path resolution

[Churchill, Dan (MN65)]

Ladies and Gentlemen,

I'm experiencing a very odd problem with path resolution on the latest
version of Cygwin, DLL: 1.3.2, installer 2.78.2.3

Basically, the problem is the following: when we run a compiler, -I options
which include cygwin paths aren't resolving, leading to include files being
missed and dying compiles. 

Attached are the mount tables and an example of the problem...

C:\cygwin\bin on /usr/bin type system (textmode)
C:\cygwin\lib on /usr/lib type system (textmode)
\\mn65-bay2\C on /Owen/c type user (textmode)
C:\cygwin on / type system (textmode)
c: on /c type user (binmode)

Compiling thus: 
cd
/c/Data/Boldstroke/OCP/OCP/Infrastructure/PlatformServices/ACE_Wrappers/ace
ccppc -fno-implicit-templates 
 
-B/c/Tornado/host/x86-win32/lib/gcc-lib/powerpc-wrs-vxworks/gcc-2.96/ 
          -DCPU=PPC604 -DVXWORKS -D_REENTRANT -ansi -fno-exceptions 
          -fno-builtin -fno-defer-pop -fvolatile -nostdlib  -W -Wall
-Wno-format
          -fno-rtti
          -DACE_LACKS_RTTI    
          -I/c/Tornado/target/h 
 
-I/c/Data/Boldstroke/OCP/OCP/Infrastructure/PlatformServices/ACE_Wrappers  
           -c  -o .obj/Basic_Types.o Basic_Types.cpp

Fails with missing headers which are present in the
/c/Data/Boldstroke/OCP/OCP/Infrastructure/PlatformServices/ACE_Wrappers
directory.

However, moving to the directory 
/c/Data/Boldstroke/OCP/OCP/Infrastructure/PlatformServices/ACE_Wrappers/ace
in bash and utilizing the following compile line results in a partial
success(until a file needs to be included from another Cygwin directory)

ccppc -fno-implicit-templates 
 
-B/c/Tornado/host/x86-win32/lib/gcc-lib/powerpc-wrs-vxworks/gcc-2.96/ 
          -DCPU=PPC604 -DVXWORKS -D_REENTRANT -ansi -fno-exceptions 
          -fno-builtin -fno-defer-pop -fvolatile -nostdlib  -W -Wall
-Wno-format
          -fno-rtti
          -DACE_LACKS_RTTI    
          -I/c/Tornado/target/h 
 
-I/c/Data/Boldstroke/OCP/OCP/Infrastructure/PlatformServices/ACE_Wrappers
          -I..  #  <----- Note relative path!  
          -c  -o .obj/Basic_Types.o Basic_Types.cpp

Any ideas why this would be happening? It seems to be a problem unique to
this machine --nobody else who uses Cygwin here has seen it before. 

ccppc is a standard GCC 2.96 cross-compiler provided as part of the
WindRiver toolkit for embedded systems.

Sincerely, 
Dan Churchill
Honeywell Labs

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Problems with path resolution

[nasser abbasi]

I am also seeing some strange path problems with 1.3.2

I say 

ls -l  /cygdrive/f/foo

and it lists it.

I say

file /cygdrive/f/foo

and I get an error 'No such file or directory'

foo is some binary file.

I could even be in the same directory, and it wont make a difference. 

But since this only affect file with 'x' bit set on them, and I know allready there is 
a problem with setting 'x' on files (it does not work), I guess this is related to the same
thing. of course all of this might not be related to your problem :)

Nasser

----- Original Message ----- 
From: "Churchill, Dan (MN65)" <churchill_dan@htc.honeywell.com>
To: <cygwin@cygwin.com>
Sent: Friday, August 24, 2001 3:24 PM
Subject: Problems with path resolution


> Ladies and Gentlemen,
> 
> I'm experiencing a very odd problem with path resolution on the latest
> version of Cygwin, DLL: 1.3.2, installer 2.78.2.3
> 
> Basically, the problem is the following: when we run a compiler, -I options
> which include cygwin paths aren't resolving, leading to include files being
> missed and dying compiles. 
> 
> Attached are the mount tables and an example of the problem...
> 
> C:\cygwin\bin on /usr/bin type system (textmode)
> C:\cygwin\lib on /usr/lib type system (textmode)
> \\mn65-bay2\C on /Owen/c type user (textmode)
> C:\cygwin on / type system (textmode)
> c: on /c type user (binmode)
> 
> Compiling thus: 
> cd
> /c/Data/Boldstroke/OCP/OCP/Infrastructure/PlatformServices/ACE_Wrappers/ace
> ccppc -fno-implicit-templates 
>  
> -B/c/Tornado/host/x86-win32/lib/gcc-lib/powerpc-wrs-vxworks/gcc-2.96/ 
>           -DCPU=PPC604 -DVXWORKS -D_REENTRANT -ansi -fno-exceptions 
>           -fno-builtin -fno-defer-pop -fvolatile -nostdlib  -W -Wall
> -Wno-format
>           -fno-rtti
>           -DACE_LACKS_RTTI    
>           -I/c/Tornado/target/h 
>  
> -I/c/Data/Boldstroke/OCP/OCP/Infrastructure/PlatformServices/ACE_Wrappers  
>            -c  -o .obj/Basic_Types.o Basic_Types.cpp
> 
> Fails with missing headers which are present in the
> /c/Data/Boldstroke/OCP/OCP/Infrastructure/PlatformServices/ACE_Wrappers
> directory.
> 
> However, moving to the directory 
> /c/Data/Boldstroke/OCP/OCP/Infrastructure/PlatformServices/ACE_Wrappers/ace
> in bash and utilizing the following compile line results in a partial
> success(until a file needs to be included from another Cygwin directory)
> 
> ccppc -fno-implicit-templates 
>  
> -B/c/Tornado/host/x86-win32/lib/gcc-lib/powerpc-wrs-vxworks/gcc-2.96/ 
>           -DCPU=PPC604 -DVXWORKS -D_REENTRANT -ansi -fno-exceptions 
>           -fno-builtin -fno-defer-pop -fvolatile -nostdlib  -W -Wall
> -Wno-format
>           -fno-rtti
>           -DACE_LACKS_RTTI    
>           -I/c/Tornado/target/h 
>  
> -I/c/Data/Boldstroke/OCP/OCP/Infrastructure/PlatformServices/ACE_Wrappers
>           -I..  #  <----- Note relative path!  
>           -c  -o .obj/Basic_Types.o Basic_Types.cpp
> 
> Any ideas why this would be happening? It seems to be a problem unique to
> this machine --nobody else who uses Cygwin here has seen it before. 
> 
> ccppc is a standard GCC 2.96 cross-compiler provided as part of the
> WindRiver toolkit for embedded systems.
> 
> Sincerely, 
> Dan Churchill
> Honeywell Labs
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Problems with path resolution

[Christopher Faylor]

On Fri, Aug 24, 2001 at 05:24:11PM -0500, Churchill, Dan  (MN65) wrote:
>Ladies and Gentlemen,
>
>I'm experiencing a very odd problem with path resolution on the latest
>version of Cygwin, DLL: 1.3.2, installer 2.78.2.3
>
>Any ideas why this would be happening? It seems to be a problem unique to
>this machine --nobody else who uses Cygwin here has seen it before. 
>
>ccppc is a standard GCC 2.96 cross-compiler provided as part of the
>WindRiver toolkit for embedded systems.

It sounds very much to me like you should be contacting WindRiver and
ask them about this.  If they are using Cygwin then they should be
prepared to support what they provide you.

Asking a mailing list to provide you with support for a commercial
product seems a little odd to me.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Problems with path resolution

[Christopher Faylor]

On Fri, Aug 24, 2001 at 11:29:57PM -0700, nasser abbasi wrote:
>I am also seeing some strange path problems with 1.3.2
>
>I say 
>
>ls -l  /cygdrive/f/foo
>
>and it lists it.
>
>I say
>
>file /cygdrive/f/foo
>
>and I get an error 'No such file or directory'
>
>foo is some binary file.

I assume that foo has a .exe extension.  ls -l will tack on a .exe to a file name if
it can't find it without the extension.  ls is probably the only cygwin utility that
will do that, with the possible exception of 'cp' (depends on the version of cp and
there are bugs in all versions).

So, the short answer is 'always add the .exe extension'.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Problems with path resolution

[nasser abbasi]

----- Original Message ----- 
 > >I say 
> >
> >ls -l  /cygdrive/f/foo
> >
> >and it lists it.
> >
> >I say
> >
> >file /cygdrive/f/foo
> >
> >and I get an error 'No such file or directory'
> >
> >foo is some binary file.
>
 

> 
> So, the short answer is 'always add the .exe extension'.
> 

Yup, that was it.  thanks. 'ls' and 'which' for example will find the file without adding '.exe', but the 'file' 
and 'nm' and few other commands will not. 

Not consistant.

A very small price to pay for the benifit of using Unix under windows I guess :)

Nasser


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Problems with path resolution

[Larry Hall (RFK Partners, Inc)]

At 02:29 AM 8/25/2001, nasser abbasi wrote:

<snip>

>But since this only affect file with 'x' bit set on them, and I know allready there is 
>a problem with setting 'x' on files (it does not work), I guess this is 

<snip>


OK, what doesn't work about it?  If you're going to make bold statements
like this, you need to back it up with something.  Also, in considering 
whether or not to make statements like this, it is a good idea to check 
existing documentation at www.cygwin.com.  In your case, you seem to be 
referring to an issue you're having with using chmod.  If that's the case, 
you should be very enlightened by the following FAQ entry:

Why doesn't chmod work?
http://www.cygwin.com/faq/faq_4.html#SEC37

I'm curious why you would make such a bold statement about setting
the execution bit after you got the response you did from your original
posting entitled "chmod +x does not work. cygwin 1.3.2, win2k."  Among 
other responses, David Starks-Browning pointed you directly to the FAQ 
entry I referenced above.  Did you not read it?  If you did, I'm even 
more perplexed by your comment above.  If you didn't, why do you spread
misinformation?




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


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Problems with path resolution

[nasser abbasi]

 
> OK, what doesn't work about it?  
 
bash-2.05$ ls -l t.t
-rw-r--r--    1 Administ None          368 Aug 21 08:33 t.t

bash-2.05$ chmod +x t.t

bash-2.05$ ls -lt t.t
-rw-r--r--    1 Administ None          368 Aug 21 08:33 t.t

I am sure there is a good reason for this and workaround (I had a quick look
at the ntsec patch/entry in the faq).

I was simply saying it does not work as is, out of the box, as it works on Unix. What is
not correct about this statment?

Nasser



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Problems with path resolution

[Larry Hall (RFK Partners, Inc)]

At 05:13 PM 8/26/2001, nasser abbasi wrote:

>  
> > OK, what doesn't work about it?  
>  
>bash-2.05$ ls -l t.t
>-rw-r--r--    1 Administ None          368 Aug 21 08:33 t.t
>
>bash-2.05$ chmod +x t.t
>
>bash-2.05$ ls -lt t.t
>-rw-r--r--    1 Administ None          368 Aug 21 08:33 t.t
>
>I am sure there is a good reason for this and workaround (I had a quick look
>at the ntsec patch/entry in the faq).


Yes, the good reason is explained in the FAQ entry that both David 
Starks-Browning and I directed you to.  You'd probably find it useful to
read.  If there is something about the content that you feel needs 
addressing, please propose alternate/additional prose.
  

>I was simply saying it does not work as is, out of the box, as it works on Unix. What is
>not correct about this statment?


Nothing.  This qualified statement, while providing no additional help to
folks with the same question who search the email archives for answers, 
is correct.  Your initial one, which simply stated that chmod doesn't work,
was completely unqualified and totally erroneous.  I wanted to pick up on
this error to help avoid confusion for others who might stumble across 
your post.  I think I've achieved that goal.



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


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Problems with path resolution

[Christopher Faylor]

On Tue, Aug 28, 2001 at 05:46:18AM +0800, bumps man wrote:
>-----Original Message-----
>From: "Gerald W. Shapiro" <gshapiro@cais.com>
>Date: Mon, 27 Aug 2001 14:10:38 -0400 (EDT)
>To: cygwin@cygwin.com
>Subject: RE: Problems with path resolution
>
>
>> I just joined this list, and my question seems similar to Dan's. And
>> perhaps it is a mingw group question, but here I go... joining the hoards
>> of ignorant newbies bothering the list
>> 
>> In one of the gprolog makefiles an auxiliary program takes a path
>> and a filename as input. Built with cygwin1.dll, fopen() in the auziliary
>> program has no problem finding /usr/local/blahblah/foo.h , but using
>> -mno-cygwin, the same is not found. If I run the no-cygwin version outside
>> the makefile, and provide a relative path, it works fine, but the
>> no-cygwin version does not recognize the full unix-style path.  My cygwin
>> installation root is c:\cygwin. 
>> 
>> Is there something dreadfully obvious that I am missing here?
>> 
>> Gerald
>> 
>
>I used to have similar issues with pathnames.  They were resolved when
>I made my root e:\ instead of e:\something\else.
>
>A non-cygwin Win32 app doesn't understand your cygwin root.

This is the answer to this issue.  Cygwin doesn't affect path
recognition in non-cygwin applications.  Use the cygpath program to
translate paths to Windows form or if an "identity" mount arrangement is
acceptable then that is another alternative.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Problems with path resolution

[bumps man]

-----Original Message-----
From: "Gerald W. Shapiro" <gshapiro@cais.com>
Date: Mon, 27 Aug 2001 14:10:38 -0400 (EDT)
To: cygwin@cygwin.com
Subject: RE: Problems with path resolution


> I just joined this list, and my question seems similar to Dan's. And
> perhaps it is a mingw group question, but here I go... joining the hoards
> of ignorant newbies bothering the list
> 
> In one of the gprolog makefiles an auxiliary program takes a path
> and a filename as input. Built with cygwin1.dll, fopen() in the auziliary
> program has no problem finding /usr/local/blahblah/foo.h , but using
> -mno-cygwin, the same is not found. If I run the no-cygwin version outside
> the makefile, and provide a relative path, it works fine, but the
> no-cygwin version does not recognize the full unix-style path.  My cygwin
> installation root is c:\cygwin. 
> 
> Is there something dreadfully obvious that I am missing here?
> 
> Gerald
> 

I used to have similar issues with pathnames.
They were resolved when I made my root e:\
instead of e:\something\else.

A non-cygwin Win32 app doesn't understand your
cygwin root.  Making your cygwin root the
"real" root on a drive, you can take advantage
of the coincidence whereupon 

/usr/local/lib/whatever

will often be interpreted as 

e:\usr\local\lib\whatever

assuming that you launched whatever it is
you are running from the e: drive.

You may have to adjust / to \ sometimes.

For one thing, this allowed emacs (which
is a straight Win32 app) to jump to the 
appropriate header files for the "next-error" 
command.

(I assume this will work for c: as well;
I just like to have cygwin root on a different
partition.)







-- 

Get your free email from www.linuxmail.org 


Powered by Outblaze

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Problems with path resolution

[Gerald W. Shapiro]

I just joined this list, and my question seems similar to Dan's. And
perhaps it is a mingw group question, but here I go... joining the hoards
of ignorant newbies bothering the list

In one of the gprolog makefiles an auxiliary program takes a path
and a filename as input. Built with cygwin1.dll, fopen() in the auziliary
program has no problem finding /usr/local/blahblah/foo.h , but using
-mno-cygwin, the same is not found. If I run the no-cygwin version outside
the makefile, and provide a relative path, it works fine, but the
no-cygwin version does not recognize the full unix-style path.  My cygwin
installation root is c:\cygwin. 

Is there something dreadfully obvious that I am missing here?

Gerald


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Problems with path resolution

['Christopher Faylor ']

I actually read this mailing list so there is no reason to Cc me.
That's why I reset the Reply-To.

For the record, I'm Cc'ing *you* because you are not, apparently,
subscribed to the cygwin mailing list.

On Mon, Aug 27, 2001 at 10:03:40AM -0500, Churchill, Dan  (MN65) wrote:
>> Asking a mailing list to provide you with support for a commercial
>> product seems a little odd to me.
>
>Since providing access to files in the file system is the job of OS, which
>for this executable is cygwin, I thought it perfectly appropriate to post to
>the _cygwin_ mailing list. I don't know for certain that this is a problem
>with cygwin, but I certainly don't know that it's _not_ a probem with
>cygwin, either.

Again, if you have received an application which uses cygwin from
someone, you should check with the someone for your support.  We have no
way of knowing how your system is set up, what version of cygwin you're
using, if the application you're using understands cygwin paths, etc.

Even if we did know all that, expecting support for a commercial
application in a public mailing list is just, IMO, wrong.  I don't want
to act as a support arm of Wind River.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Problems with path resolution

[Churchill, Dan (MN65)]

> Asking a mailing list to provide you with support for a commercial
> product seems a little odd to me.

> cgf

Let me be clear.  The particular error, which I previously described as
"Fails with missing headers" is a message that says the file is not found
(my apologies, I don't have the verbatim text in front of me, nor a way to
run it again right now as I am home for the day).  The files that it says
are missing, are in fact, right where they belong.  The problem is that the
compiler can only find them if relative paths (./ ../, etc.) are provided in
the build command, not if the entire path is specified. This is an extremely
large compile, and it is not feasible, nor should it be necessary, for us to
try to change every instance of each call in all of the makefiles to use
relative paths.  As stated in my original post, the pathname specified in
the -I parameter to the compiler is correct, down to the last letter in both
spelling and capitalization.  The path does access my c: drive via the a /c
mount point, listed in the mount table in the original post, and the
suspicion was that somehow that mount point isn't functioning correctly,
either because of a misconfiguration on my part or because of a bug in
cygwin.

Since providing access to files in the file system is the job of OS, which
for this executable is cygwin, I thought it perfectly appropriate to post to
the _cygwin_ mailing list. I don't know for certain that this is a problem
with cygwin, but I certainly don't know that it's _not_ a probem with
cygwin, either. I simply wanted to go fishing for anyone who may have
experienced anything like this, with any type of application running under
cygwin.  If there is a more appropriate place to post, please let me know.
Wind River technical support is certainly a valid suggestion that I will use
if I need to.

Respectfully,
Dan Churchill

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/