C/NT Problems - Compiling

"Substitution cannot be performed..."

PFE produces the error "Substitution cannot be performed in the specified command line as either no file is currently open, or the current window does not contain a named file"

This is caused by one of two things.

You have the wrong window in focus.: (eg. you have a compiler output window selected). You need to select the window with the c-code in it.
Your c-code has no filename.: (ie. you have not saved it yet) You should save your c-code first. This will give it a filename to substitute for the %f and %n in the command line. The filename must end in .C

"The name specified is not recognized..."

This can be caused by two things.

NT has somehow unmounted drive W:: To Fix this you need to see Drive W: Not Mounted
NT has lost your path information: Installing some other packages (and occasionally when NT feels like it) can remove the location of the gcc compiler from your path environment variable. To put it back select Start, Settings, Control Panel and then double-click on System The System Properties window should then appear. From this select the Environment tab and select Path from the User Variables list. This should fill in the Variable and Value boxes at the bottom of the window. The Value box should include the following:-
%Path%;w:\Djgpp\bin
It may have more but it must have at least that. It does not have that then you should add ;w:\Djgpp\bin to the end (do not overwrite what is already there). The Press the Set button, followed by the Apply button. Then you MUST LOG-OUT AND BACK IN otherwise NT will not recognise the change to the path.

If after checking these two you still get the same error message then you can try changing the compile command. Click on the compile button in PFE and instead of just clicking on OK, change the Command from:-
gcc %f -o %n.exe to w:\Djgpp\bin\gcc %f -o %n.exe

"<filename>: file not recognized:..."

When you try and compile your code you get back a Compiler Output window which contains "<filename>: file not recognized: File format not recognized"

This is cause by not saving the file with a ".c" extension. C-Code must end in .c For example assess1.c

"...No such file or directory (ENOENT)..."

When you try and compile your code you get the error message:-
gcc.exe: <filename>: No such file or directory (ENOENT) gcc.exe: No input files

This is most often caused by the filename you have used being too long. Although Windows NT can handle long filenames, gcc is a DOS application and can only handle filenames 8 characters long and 3 for the extension. So it is best to keep to short filenames. The easiest way to do this is to just select Save As from the File menu and give your code a new (and shorter) name.

"Undefined symbol sqrt first referenced in file ..."

You are only likely to get this error message if you are compiling your code on UNIX. To fix this, you need to tell gcc to link the maths library with a command like:-
gcc -o assess assess.c -lm

"<filename>: In function `main':..."

If you try compiling your code and get a list of error messages that look something like :-
<filename>: In function `main': <filename>:76: ...... Then the compiler is notifying you of errors in your source code (rather than any system problems). It is up to you to find and fix these errors yourself. However, here are a few tips on how to proceed.

Start with the first error

Always start with the first compiler error and try and fix that first. It is quite possible that some of the earlier errors also caused some of the later ones and so fixing the first error may cause later ones to vanish.

Re-compile every so often

If you make any changes and fix any errors this may have an effect on later errors (as mentioned above) especially if you are fixing parse errors. So re-compiling may cause the list of errors to become very much shorter.

Don't try to fix too many errors at once

The more errors the compiler encounters the more "confused" it tends to become and so the less likely the errors will be "real." So only fixing a few errors at a time should mean less time looking for errors that don't really exist.

Use the line numbers

Most of the error messages come with a line number which refers to the approximate line in your source code where the error has occured. The error will normalcy be within a line or two (probably lines before rather than after). Also be careful if you make any changes that add or remove lines from the code as the later line numbers will have changed.

Look out for missing ;'s and }'s

A lot of errors in compiling are caused by forgetting to put these characters in the code. So it is worth looking out for them. It is a lot easier if the code is well laid out. For example it is easier to spot a missing } character in:-

   for (i=1;i<10;i++)
   {
      if (i <= oval)
      {
          /*Do Something*/
      }else{
          /*Something Else */
   }

Than it would be in:-


   for (i=1;i<10;i++)
   {
      if (i <= oval)
      {
     /*Do Something*/
      }else{
           /*Something Else */
   }