tags:

views:

330

answers:

1

My basic problem is that if I run GCC from the windows command line (cmd.exe in Windows XP) and it does nothing: no .o files are created, no error messages, nothing. It will only throw an error message if I use DOS-style paths, but nothing else. When I run from the Cygwin shell then it will throws error messages as appropriate for the errors in the source and produces the .o files as it needs. Using 'make' from the DOS command line doesn't work either. Has anyone encountered this behavior before?

A: 

I've actually made some progress on this. Background:

I have WinAVR installed and its bin directories set in my PATH. WinAVR is GCC and associated development utilities but for the AVR 8-bit microcontroller. It shares many utility names with regular GCC.

In the past I remember Cygwin putting its bin directories in the PATH. It didn't seem to do this this time, so I put 'C:\cygwin\bin' into the PATH and then later 'C:\cygwin\usr\bin' there as well.

The latest release of Cygwin has issues with the way it handles files. Basically, gcc.exe is not an executable, but a type of symlink to the actual executable (which is either gcc-3.exe or gcc-4.exe depending on what you have installed). In the BASH shell these symlinks are easily resolved, in cmd.exe they are not. This means that if you attempt to enter 'gcc' into cmd.exe as a command it will respond 'Access is denied'. The solution for that is to call the actual GCC file name (gcc-4) instead of the symlink.

The solution seems to have come by rearranging my PATH. To edit the PATH environment variable, right click on 'My Computer' and go to properties, then Advanced and then Environment Variables. Under 'System Variables' find 'Path' and double click it to edit. Remove all entries that have C:\cygwin in them and then go to the FRONT of the PATH and enter them there. For me it was C:\cygwin\bin and C:\cygwin\usr\bin. The important part for me was making sure that the Cygwin entries were before the WinAVR entries. I noticed that when I tried to call 'make' in cmd.exe it was calling the WinAVR version instead of the Cygwin version. This lead me to rearrange my path and after some fooling around it became clear that using gcc-4 from the cmd.exe shell was working. It then worked in Code::Blocks as well and I was off.

Alternatively, it might have just fixed itself from something else entirely. Computers have a way of doing that.

Stephen Friederichs