Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Delivered-To: fixup-cygwin AT cygwin DOT com@fixme From: "Paul G." Organization: Paul G. To: cygwin AT cygwin DOT com Date: Sun, 16 Dec 2001 15:46:52 -0800 MIME-Version: 1.0 Subject: Re: Permission denied running programs in other directories Reply-to: pgarceau AT qwest DOT net Message-ID: <3C1CC1EC.16365.5373A6@localhost> In-reply-to: <3C1BEDD8.6090407@cnpbagwell.com> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body 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 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/