Mail Archives: cygwin/2001/12/16/18:48:03
Hi folks,
disclaimer: can't say with certainty (99%) that what it appears to be is actually the case. This is more like me thinking
out loud than anything else.
On 15 Dec 2001 at 18:42, Chris Bagwell wrote:
> Hello,
>
> I am having problems running some development programs and could use
> some help.
>
> I have been using Cygwin successfully running Windows 98. Actually,
> I'm running it under Linux using the program Win4Lin. This causes the
> filesystem to appear a little differently then under real windows
> since its not using direct-to-disk FAT drivers. I'm sure this is
> related to part of the problem. I'm not sure but they may be treated
> as network drives.
It really looks to be very similar to a /root vs. Win4Lin /root access conflict.
>
> Somewhere after a cygwin upgrade I noticed that when I tried to
> compile programs it would give me the following error:
>
> gcc: installation problem, cannot exec
> '/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/b
> in/as.exe': Permission denied
Again, it may be that you are getting conflicts between what Win4Lin considers /root and what your Linux
system thinks of as $ROOT. (You may need to give Win4Lin su status. Just a guess based on behavior I noted
when I used Linux extensively many years ago, but seems to make sense.)
I am not familiar with how Win4Lin sets things up. Believe (again, not certain) that setup.exe determines
Cygwin /root when it does an "install from web". Under MS Windows, the assumption is that once Cygwin /root is set
it does not need to be re-initialized, not ever. (Linux needs to always have /root defined.) Now, if Linux is over-riding
or re-defining $ROOT settings when Win4Lin is shut down, it would make sense that the Cygwin /root would always
need to be re-initialized/defined whenever Win4Lin is restarted. In extreme cases, this could be accomplished with
some sort of SU priority shell script which is run whenever Win4Lin is launched.
>
> I am able to reproduce the same error if I type the follow from the
> bash prompt:
>
> /usr/i686-pc-cygwin/bin/as.exe
> BASH: /usr/i686-pc-cygwin/bin/as.exe: Permission denied
>
> It will run fine if I run it from within that directory:
ok...so when PWD is set to /usr/i686-pc-cygwin/bin:
>
> cd /usr/i686-pc-cygwin/bin
> as.exe
> [starts accepting input until I type ctrl-d]
It works until you try and access a term i/o (console?) directive.
Other possibility, you're missing a $PATH$ or symlink(hard) reference. Again, uncertain on this, so it is
largely speculation, ctrl-d is typically a call to Cygwin console/term driver, isn't it? Does ctrl-d run when $PWD is set
(Win4Lin) to Cygwin /root (Under MS-Windows <somedrv:\somedirname> is defined as "Cygwin /root" -- same likely
applies for Win4Lin)?
Again, looks like a conflict between what Cygwin considers "/root" for MS-Windows and what Linux considers
/root for System ($ROOT) once Win4Lin (process?) has been shut down and restarted.
>
> For some extra strange stuff, if I run "strace
> /usr/i686-pc-cygwin/bin/as.exe" I get the following message:
>
> strace.xe: error creating process /usr/i686-pc-cygwin/bin/as.exe,
> (error 2)
Looks like user priority ("Linux su" vs. "Linux user") conflict.
>
> And finally, if I reinstall the binutil package using the setup
> program then it starts working... By that I mean it works until I shut
> down windows... When I restart it I will get the same behavior as
> described above. Its as if the setup program is enabling some file or
> directory permissions that are not setup upon bootup.
Hope this helps.
Paul G.
--
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/
- Raw text -