4.1 What is GCC?


GCC is the C compiler provided free to the computer community by GNU. It is the compiler of choice for working with muds on a Unix system, and recently has become available for Microsoft Windows 95 and NT in the Cygnus package. If your system has gcc installed, you are strongly advised to use it for your compilation needs, as it provides a much more coherent and solid base than do some standard unix based 'cc' compilers.


4.2 What can I do with the Makefile?


When you type 'make' to compile your code, the options supplied to the compiler are held in the file called 'Makefile' in your src/ directory. The makefile supplied with ROM is very good for showing many warnings and compiling efficient code, but you should not be afraid to look at the file. Most notably, if you create new .c files that you want to add to your mud, this needs added to the makefile. If you notice, the makefile has a section containing a list of .o files- these are the names of all your .c files with an .o extension instead. Therefore, if you wish to add a new file called "myfile.c", you would append "myfile.o" to the end of this list. Note that a backslash is used to indicate the list continues on the following line.

For some Operating Systems, you may need to make additional changes, such as specifying certain libraries the compiler needs to include, certain values to define etc. See question 2.3 for some relevant points for a number of commonly used OS's.


4.3 What are the steps of the compilation process?



There are two main stages to the compilation process, though it should be noted that each of these can be subdivided.

Firstly, each .c file is compiled into a form that the computer understands, known as an object file. The object file for a given .c file has the same name but with a .o extension rather than .c. If all the .c files successfully compile without errors then the .o files are all linked together into a file called 'rom', which is the main mud executable.

These two stages can easily fail, and the following sections will attempt to explain some of the more common compilation error messages. It may be helpful to keep in mind the following list of what is most likely to go wrong in each stage:
Compilation of .c files

- Syntax errors, such as forgetting a semicolon, adding too many brackets to an expression and such.
- Typos, for example using '=' instead of '==' in a equality test, mistyping a variable name.
- Forgetting to declare variables used
Mixing up types, most commonly with pointers
Linking of the Executable
- Declaring a function in two places
- Declaring a function header, using the function but never coding the function body
Having a typo in either the function body or prototype that means the linker can't relate the two
The following types of errors will *not* be caught:
- Accessing a null pointer
- Overrunning an array boundary
Improperly initialising variables, especially when involving the reinitialising of those on the recycle lists
These last few can cause the mud to crash horribly, but the code will compile fine. It is therefore important to remember that just because the code compiles that it is not necessarily correct. More insiduous is the fact that overrunning an array boundary for example, may not crash the mud when it happens, but some time later, making the problem even trickier to find.

4.4 My code won't compile..why?


These are some of the more 'popular' gcc error/warning messages and possible causes:

4.4.1 'Parse error..'


The compiler found a symbol that it wasn't expecting.. for example, an extra paren on a complex if check, a semicolon placed after a function body header, a semicolon omitted from the previous line amongst others. The error is not always on the line mentioned by gcc, but may be the previous line.


4.4.2 'Assignment makes integer from pointer without a cast..'


This error arises when you assign a pointer to a non-pointer variable.. for example: int I = NULL ; or CHAR_DATA ch, *vch ; ch = vch ;


4.4.3 'Implicit declaration of function..'


You have tried to use a function that the compiler has no definition of. His can arise if you mistype the function name, haven't included a necessary header file, or simply haven't coded the function yet.


4.4.4 '.. declared here - not in a function'


This error arises when you are using a variable that hasn't been defined. This can be due to a typo or forgetting to declare the variable previously.


4.5 But why can't I just ignore warnings?


Because though they don't stop your code compiling, they can indicate code problems that may very well crash the mud once running. It's probably a good idea to get rid of all warnings unless you know exactly what you are doing.


4.6 What options may I want to add to the Makefile?


Lots are available. Look at the documentation for full lists of available bells and whistles, but commonly used additions to the c_flags are:
-Wshadow - warn if a variable is declared that shadows another
-Wstrict-prototypes - enforces stricter function prototyping, no more fn() ; nonsense.

4.7 Why do I get a signal 11 error during compilation?


There are a few possible causes for this, but the most frequent is bad memory. When compiling, GCC creates some very large data structures in memory that it traverses many times, and a bad memory module will often cause things to break at this point.


For further discussions of this issue, consult:
http://www.bitwizard.nl/sig11/
http://haven.orisis.net/~dingo/rom-mud.html


Main Rom Page Index 1 2 3 4 5 6 7 8