幽灵狼

狼团队中的每一位成员,共同承担团体生存的责任, 并为此付出自己的独特技能和力量。 我是狼, 相信自己, 相信伙伴。
  IT博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

 

2.4 Compiling with cc

This section deals only with the GNU compiler for C and C++, since that comes with the base FreeBSD system. It can be invoked by either cc or gcc. The details of producing a program with an interpreter vary considerably between interpreters, and are usually well covered in the documentation and on-line help for the interpreter.

Once you have written your masterpiece, the next step is to convert it into something that will (hopefully!) run on FreeBSD. This usually involves several steps, each of which is done by a separate program.

  1. Pre-process your source code to remove comments and do other tricks like expanding macros in C.

  2. Check the syntax of your code to see if you have obeyed the rules of the language. If you have not, it will complain!

  3. Convert the source code into assembly language--this is very close to machine code, but still understandable by humans. Allegedly. [1]

  4. Convert the assembly language into machine code--yep, we are talking bits and bytes, ones and zeros here.

  5. Check that you have used things like functions and global variables in a consistent way. For example, if you have called a non-existent function, it will complain.

  6. If you are trying to produce an executable from several source code files, work out how to fit them all together.

  7. Work out how to produce something that the system's run-time loader will be able to load into memory and run.

  8. Finally, write the executable on the filesystem.

The word compiling is often used to refer to just steps 1 to 4--the others are referred to as linking. Sometimes step 1 is referred to as pre-processing and steps 3-4 as assembling.

Fortunately, almost all this detail is hidden from you, as cc is a front end that manages calling all these programs with the right arguments for you; simply typing

% cc foobar.c

will cause foobar.c to be compiled by all the steps above. If you have more than one file to compile, just do something like

% cc foo.c bar.c

Note that the syntax checking is just that--checking the syntax. It will not check for any logical mistakes you may have made, like putting the program into an infinite loop, or using a bubble sort when you meant to use a binary sort. [2]

There are lots and lots of options for cc, which are all in the manual page. Here are a few of the most important ones, with examples of how to use them.

-o filename

The output name of the file. If you do not use this option, cc will produce an executable called a.out. [3]

% cc foobar.c               executable is a.out
% cc -o foobar foobar.c executable is foobar

-c

Just compile the file, do not link it. Useful for toy programs where you just want to check the syntax, or if you are using a Makefile.

% cc -c foobar.c

This will produce an object file (not an executable) called foobar.o. This can be linked together with other object files into an executable.

-g

Create a debug version of the executable. This makes the compiler put information into the executable about which line of which source file corresponds to which function call. A debugger can use this information to show the source code as you step through the program, which is very useful; the disadvantage is that all this extra information makes the program much bigger. Normally, you compile with -g while you are developing a program and then compile a “release version” without -g when you are satisfied it works properly.

% cc -g foobar.c

This will produce a debug version of the program. [4]

-O

Create an optimized version of the executable. The compiler performs various clever tricks to try to produce an executable that runs faster than normal. You can add a number after the -O to specify a higher level of optimization, but this often exposes bugs in the compiler's optimizer. For instance, the version of cc that comes with the 2.1.0 release of FreeBSD is known to produce bad code with the -O2 option in some circumstances.

Optimization is usually only turned on when compiling a release version.

% cc -O -o foobar foobar.c

This will produce an optimized version of foobar.

The following three flags will force cc to check that your code complies to the relevant international standard, often referred to as the ANSI standard, though strictly speaking it is an ISO standard.

-Wall

Enable all the warnings which the authors of cc believe are worthwhile. Despite the name, it will not enable all the warnings cc is capable of.

-ansi

Turn off most, but not all, of the non-ANSI C features provided by cc. Despite the name, it does not guarantee strictly that your code will comply to the standard.

-pedantic

Turn off all cc's non-ANSI C features.

Without these flags, cc will allow you to use some of its non-standard extensions to the standard. Some of these are very useful, but will not work with other compilers--in fact, one of the main aims of the standard is to allow people to write code that will work with any compiler on any system. This is known as portable code.

Generally, you should try to make your code as portable as possible, as otherwise you may have to completely rewrite the program later to get it to work somewhere else--and who knows what you may be using in a few years time?

% cc -Wall -ansi -pedantic -o foobar foobar.c

This will produce an executable foobar after checking foobar.c for standard compliance.

-llibrary

Specify a function library to be used at link time.

The most common example of this is when compiling a program that uses some of the mathematical functions in C. Unlike most other platforms, these are in a separate library from the standard C one and you have to tell the compiler to add it.

The rule is that if the library is called libsomething.a, you give cc the argument -lsomething. For example, the math library is libm.a, so you give cc the argument -lm. A common “gotcha” with the math library is that it has to be the last library on the command line.

% cc -o foobar foobar.c -lm

This will link the math library functions into foobar.

If you are compiling C++ code, you need to add -lg++, or -lstdc++ if you are using FreeBSD 2.2 or later, to the command line argument to link the C++ library functions. Alternatively, you can run c++ instead of cc, which does this for you. c++ can also be invoked as g++ on FreeBSD.

% cc -o foobar foobar.cc -lg++     For FreeBSD 2.1.6 and earlier
% cc -o foobar foobar.cc -lstdc++ For FreeBSD 2.2 and later
% c++ -o foobar foobar.cc

Each of these will both produce an executable foobar from the C++ source file foobar.cc. Note that, on UNIX® systems, C++ source files traditionally end in .C, .cxx or .cc, rather than the MS-DOS® style .cpp (which was already used for something else). gcc used to rely on this to work out what kind of compiler to use on the source file; however, this restriction no longer applies, so you may now call your C++ files .cpp with impunity!

2.4.1 Common cc Queries and Problems

2.4.1.1. I am trying to write a program which uses the sin() function and I get an error like this. What does it mean?
2.4.1.2. All right, I wrote this simple program to practice using -lm. All it does is raise 2.1 to the power of 6.
2.4.1.3. So how do I fix this?
2.4.1.4. I compiled a file called foobar.c and I cannot find an executable called foobar. Where has it gone?
2.4.1.5. OK, I have an executable called foobar, I can see it when I run ls, but when I type in foobar at the command prompt it tells me there is no such file. Why can it not find it?
2.4.1.6. I called my executable test, but nothing happens when I run it. What is going on?
2.4.1.7. I compiled my program and it seemed to run all right at first, then there was an error and it said something about “core dumped”. What does that mean?
2.4.1.8. Fascinating stuff, but what I am supposed to do now?
2.4.1.9. When my program dumped core, it said something about a “segmentation fault”. What is that?
2.4.1.10. Sometimes when I get a core dump it says “bus error”. It says in my UNIX book that this means a hardware problem, but the computer still seems to be working. Is this true?
2.4.1.11. This dumping core business sounds as though it could be quite useful, if I can make it happen when I want to. Can I do this, or do I have to wait until there is an error?

2.4.1.1. I am trying to write a program which uses the sin() function and I get an error like this. What does it mean?

/var/tmp/cc0143941.o: Undefined symbol `_sin' referenced from text segment

When using mathematical functions like sin(), you have to tell cc to link in the math library, like so:

% cc -o foobar foobar.c -lm

2.4.1.2. All right, I wrote this simple program to practice using -lm. All it does is raise 2.1 to the power of 6.

#include <stdio.h>

int main() {
float f;

f = pow(2.1, 6);
printf("2.1 ^ 6 = %f\n", f);
return 0;
}

and I compiled it as:

% cc temp.c -lm

like you said I should, but I get this when I run it:

% ./a.out
2.1 ^ 6 = 1023.000000

This is not the right answer! What is going on?

When the compiler sees you call a function, it checks if it has already seen a prototype for it. If it has not, it assumes the function returns an int, which is definitely not what you want here.

2.4.1.3. So how do I fix this?

The prototypes for the mathematical functions are in math.h. If you include this file, the compiler will be able to find the prototype and it will stop doing strange things to your calculation!

#include <math.h>
#include <stdio.h>

int main() {
...

After recompiling it as you did before, run it:

% ./a.out
2.1 ^ 6 = 85.766121

If you are using any of the mathematical functions, always include math.h and remember to link in the math library.

2.4.1.4. I compiled a file called foobar.c and I cannot find an executable called foobar. Where has it gone?

Remember, cc will call the executable a.out unless you tell it differently. Use the -o filename option:

% cc -o foobar foobar.c

2.4.1.5. OK, I have an executable called foobar, I can see it when I run ls, but when I type in foobar at the command prompt it tells me there is no such file. Why can it not find it?

Unlike MS-DOS, UNIX does not look in the current directory when it is trying to find out which executable you want it to run, unless you tell it to. Either type ./foobar, which means “run the file called foobar in the current directory”, or change your PATH environment variable so that it looks something like

bin:/usr/bin:/usr/local/bin:.

The dot at the end means “look in the current directory if it is not in any of the others”.

2.4.1.6. I called my executable test, but nothing happens when I run it. What is going on?

Most UNIX systems have a program called test in /usr/bin and the shell is picking that one up before it gets to checking the current directory. Either type:

% ./test

or choose a better name for your program!

2.4.1.7. I compiled my program and it seemed to run all right at first, then there was an error and it said something about “core dumped”. What does that mean?

The name core dump dates back to the very early days of UNIX, when the machines used core memory for storing data. Basically, if the program failed under certain conditions, the system would write the contents of core memory to disk in a file called core, which the programmer could then pore over to find out what went wrong.

2.4.1.8. Fascinating stuff, but what I am supposed to do now?

Use gdb to analyze the core (see Section 2.6).

2.4.1.9. When my program dumped core, it said something about a “segmentation fault”. What is that?

This basically means that your program tried to perform some sort of illegal operation on memory; UNIX is designed to protect the operating system and other programs from rogue programs.

Common causes for this are:

  • Trying to write to a NULL pointer, eg

    char *foo = NULL;
    strcpy(foo, "bang!");

  • Using a pointer that has not been initialized, eg

    char *foo;
    strcpy(foo, "bang!");

    The pointer will have some random value that, with luck, will point into an area of memory that is not available to your program and the kernel will kill your program before it can do any damage. If you are unlucky, it will point somewhere inside your own program and corrupt one of your data structures, causing the program to fail mysteriously.

  • Trying to access past the end of an array, eg

    int bar[20];
    bar[27] = 6;

  • Trying to store something in read-only memory, eg

    char *foo = "My string";
    strcpy(foo, "bang!");

    UNIX compilers often put string literals like "My string" into read-only areas of memory.

  • Doing naughty things with malloc() and free(), eg

    char bar[80];
    free(bar);

    or

    char *foo = malloc(27);
    free(foo);
    free(foo);

Making one of these mistakes will not always lead to an error, but they are always bad practice. Some systems and compilers are more tolerant than others, which is why programs that ran well on one system can crash when you try them on an another.

2.4.1.10. Sometimes when I get a core dump it says “bus error”. It says in my UNIX book that this means a hardware problem, but the computer still seems to be working. Is this true?

No, fortunately not (unless of course you really do have a hardware problem...). This is usually another way of saying that you accessed memory in a way you should not have.

2.4.1.11. This dumping core business sounds as though it could be quite useful, if I can make it happen when I want to. Can I do this, or do I have to wait until there is an error?

Yes, just go to another console or xterm, do

% ps

to find out the process ID of your program, and do

% kill -ABRT pid

where pid is the process ID you looked up.

This is useful if your program has got stuck in an infinite loop, for instance. If your program happens to trap SIGABRT, there are several other signals which have a similar effect.

Alternatively, you can create a core dump from inside your program, by calling the abort() function. See the manual page of abort(3) to learn more.

If you want to create a core dump from outside your program, but do not want the process to terminate, you can use the gcore program. See the manual page of gcore(1) for more information.

Notes

[1]

To be strictly accurate, cc converts the source code into its own, machine-independent p-code instead of assembly language at this stage.

[2]

In case you did not know, a binary sort is an efficient way of sorting things into order and a bubble sort is not.

[3]

The reasons for this are buried in the mists of history.

[4]

Note, we did not use the -o flag to specify the executable name, so we will get an executable called a.out. Producing a debug version called foobar is left as an exercise for the reader!

This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.

posted @ 2005-11-11 15:23 幽灵狼 阅读(223) | 评论 (0)编辑 收藏

2.5 Make

2.5.1 What is make?

When you are working on a simple program with only one or two source files, typing in

% cc file1.c file2.c

is not too bad, but it quickly becomes very tedious when there are several files--and it can take a while to compile, too.

One way to get around this is to use object files and only recompile the source file if the source code has changed. So we could have something like:

% cc file1.o file2.o ... file37.c ...

if we had changed file37.c, but not any of the others, since the last time we compiled. This may speed up the compilation quite a bit, but does not solve the typing problem.

Or we could write a shell script to solve the typing problem, but it would have to re-compile everything, making it very inefficient on a large project.

What happens if we have hundreds of source files lying about? What if we are working in a team with other people who forget to tell us when they have changed one of their source files that we use?

Perhaps we could put the two solutions together and write something like a shell script that would contain some kind of magic rule saying when a source file needs compiling. Now all we need now is a program that can understand these rules, as it is a bit too complicated for the shell.

This program is called make. It reads in a file, called a makefile, that tells it how different files depend on each other, and works out which files need to be re-compiled and which ones do not. For example, a rule could say something like “if fromboz.o is older than fromboz.c, that means someone must have changed fromboz.c, so it needs to be re-compiled.” The makefile also has rules telling make how to re-compile the source file, making it a much more powerful tool.

Makefiles are typically kept in the same directory as the source they apply to, and can be called makefile, Makefile or MAKEFILE. Most programmers use the name Makefile, as this puts it near the top of a directory listing, where it can easily be seen. [1]

2.5.2 Example of using make

Here is a very simple make file:

foo: foo.c
cc -o foo foo.c

It consists of two lines, a dependency line and a creation line.

The dependency line here consists of the name of the program (known as the target), followed by a colon, then whitespace, then the name of the source file. When make reads this line, it looks to see if foo exists; if it exists, it compares the time foo was last modified to the time foo.c was last modified. If foo does not exist, or is older than foo.c, it then looks at the creation line to find out what to do. In other words, this is the rule for working out when foo.c needs to be re-compiled.

The creation line starts with a tab (press the tab key) and then the command you would type to create foo if you were doing it at a command prompt. If foo is out of date, or does not exist, make then executes this command to create it. In other words, this is the rule which tells make how to re-compile foo.c.

So, when you type make, it will make sure that foo is up to date with respect to your latest changes to foo.c. This principle can be extended to Makefiles with hundreds of targets--in fact, on FreeBSD, it is possible to compile the entire operating system just by typing make world in the appropriate directory!

Another useful property of makefiles is that the targets do not have to be programs. For instance, we could have a make file that looks like this:

foo: foo.c
cc -o foo foo.c

install:
cp foo /home/me

We can tell make which target we want to make by typing:

% make target

make will then only look at that target and ignore any others. For example, if we type make foo with the makefile above, make will ignore the install target.

If we just type make on its own, make will always look at the first target and then stop without looking at any others. So if we typed make here, it will just go to the foo target, re-compile foo if necessary, and then stop without going on to the install target.

Notice that the install target does not actually depend on anything! This means that the command on the following line is always executed when we try to make that target by typing make install. In this case, it will copy foo into the user's home directory. This is often used by application makefiles, so that the application can be installed in the correct directory when it has been correctly compiled.

This is a slightly confusing subject to try to explain. If you do not quite understand how make works, the best thing to do is to write a simple program like “hello world” and a make file like the one above and experiment. Then progress to using more than one source file, or having the source file include a header file. The touch command is very useful here--it changes the date on a file without you having to edit it.

2.5.3 Make and include-files

C code often starts with a list of files to include, for example stdio.h. Some of these files are system-include files, some of them are from the project you are now working on:

#include <stdio.h>
#include "foo.h"

int main(....

To make sure that this file is recompiled the moment foo.h is changed, you have to add it in your Makefile:

foo: foo.c foo.h

The moment your project is getting bigger and you have more and more own include-files to maintain, it will be a pain to keep track of all include files and the files which are depending on it. If you change an include-file but forget to recompile all the files which are depending on it, the results will be devastating. gcc has an option to analyze your files and to produce a list of include-files and their dependencies: -MM.

If you add this to your Makefile:

depend:
gcc -E -MM *.c > .depend

and run make depend, the file .depend will appear with a list of object-files, C-files and the include-files:

foo.o: foo.c foo.h

If you change foo.h, next time you run make all files depending on foo.h will be recompiled.

Do not forget to run make depend each time you add an include-file to one of your files.

2.5.4 FreeBSD Makefiles

Makefiles can be rather complicated to write. Fortunately, BSD-based systems like FreeBSD come with some very powerful ones as part of the system. One very good example of this is the FreeBSD ports system. Here is the essential part of a typical ports Makefile:

MASTER_SITES=   ftp://freefall.cdrom.com/pub/FreeBSD/LOCAL_PORTS/
DISTFILES= scheme-microcode+dist-7.3-freebsd.tgz

.include <bsd.port.mk>

Now, if we go to the directory for this port and type make, the following happens:

  1. A check is made to see if the source code for this port is already on the system.

  2. If it is not, an FTP connection to the URL in MASTER_SITES is set up to download the source.

  3. The checksum for the source is calculated and compared it with one for a known, good, copy of the source. This is to make sure that the source was not corrupted while in transit.

  4. Any changes required to make the source work on FreeBSD are applied--this is known as patching.

  5. Any special configuration needed for the source is done. (Many UNIX® program distributions try to work out which version of UNIX they are being compiled on and which optional UNIX features are present--this is where they are given the information in the FreeBSD ports scenario).

  6. The source code for the program is compiled. In effect, we change to the directory where the source was unpacked and do make--the program's own make file has the necessary information to build the program.

  7. We now have a compiled version of the program. If we wish, we can test it now; when we feel confident about the program, we can type make install. This will cause the program and any supporting files it needs to be copied into the correct location; an entry is also made into a package database, so that the port can easily be uninstalled later if we change our mind about it.

Now I think you will agree that is rather impressive for a four line script!

The secret lies in the last line, which tells make to look in the system makefile called bsd.port.mk. It is easy to overlook this line, but this is where all the clever stuff comes from--someone has written a makefile that tells make to do all the things above (plus a couple of other things I did not mention, including handling any errors that may occur) and anyone can get access to that just by putting a single line in their own make file!

If you want to have a look at these system makefiles, they are in /usr/share/mk, but it is probably best to wait until you have had a bit of practice with makefiles, as they are very complicated (and if you do look at them, make sure you have a flask of strong coffee handy!)

2.5.5 More advanced uses of make

Make is a very powerful tool, and can do much more than the simple example above shows. Unfortunately, there are several different versions of make, and they all differ considerably. The best way to learn what they can do is probably to read the documentation--hopefully this introduction will have given you a base from which you can do this.

The version of make that comes with FreeBSD is the Berkeley make; there is a tutorial for it in /usr/share/doc/psd/12.make. To view it, do

% zmore paper.ascii.gz

in that directory.

Many applications in the ports use GNU make, which has a very good set of “info” pages. If you have installed any of these ports, GNU make will automatically have been installed as gmake. It is also available as a port and package in its own right.

To view the info pages for GNU make, you will have to edit the dir file in the /usr/local/info directory to add an entry for it. This involves adding a line like

 * Make: (make).                 The GNU Make utility.

to the file. Once you have done this, you can type info and then select make from the menu (or in Emacs, do C-h i).

Notes

[1]

They do not use the MAKEFILE form as block capitals are often used for documentation files like README.

This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

For questions about FreeBSD, read the documentation before contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.

posted @ 2005-11-11 15:23 幽灵狼 阅读(227) | 评论 (0)编辑 收藏

通常我们所说的comp.os.*等新闻组到底在什么服务器上呢?这是利用Outlook等工具阅读新闻组时所要解决的问题,我们可以不管这个新闻组的源 到底在哪里,我们所关心的是哪个服务器提供这个新闻组的服务,让我们可以订阅这个新闻组。下面这个站点可以帮我们解决这个问题:
http://freenews.maxbaud.net/
通过groups.google.com阅读新闻组也是个很好的选择,可以让我们找到自己感兴趣的新闻组

posted @ 2005-11-11 15:22 幽灵狼 阅读(207) | 评论 (0)编辑 收藏

仅列出标题
共4页: 1 2 3 4