FreeBSD Problem Report Wizard -- Source Fails To Compile

There are several common problems. Let us try to eliminate these first.

Base system compilation failures

If something in the base system fails to compile, we first need to decided if the problem is already known. If so, there is probably no reason to report it.

The first thing that you should do is check the src/UPDATING file (in general, you should do this before any source upgrades). This file contains information that describes changes made to the base system that are likely to affect users. In some cases, you must make changes to your configuration files to keep up with committed changes. (This is especially true for the -current branch; users of -current need to understand that disruptive changes can and do happen.)

For other compilation problems, you should know that in general such things are noticed quickly. (If a developer has already noticed the problem, then it is most likely going to be fixed within a few hours. The best thing to do in this case is simply wait for a commit to happen to fix it, and then re-update and try again.)

Developers find out about problems in one of two ways:

  1. a dedicated set of machines, called the source tinderboxes, continually build the latest source from each FreeBSD branch (e.g. -current or -stable or and reports errors to the appropriate mailing list (e.g. freebsd-current) or freebsd-stable.
  2. Most of the FreeBSD source developers run -current and update constantly, so they may even notice before the tinderboxes do.

You can take a look at the summary of the latest state of the tinderbox to see if the tinderbox has already noticed the problem. (In general it will take only a few hours for this to happen). A failed build is shown in red.

You can also look at the latest commits via cvs-src, to find out if one has already been made. By convention, commits are first made to HEAD (which means the -current branch), then Merged From Current (MFCed) to the other branches. A commit to HEAD is not specifically labeled; an MFC is labeled as something like "(Branch: RELENG_6)".

Finally, you can take a look at the PR database to see if the problem has already been reported. Most problems of this sort tend to be reported in either the kern, misc, i386, or amd64 categories.

Again, if the problem has already been reported, then it is best to simply wait.

If the problem has not yet been reported

Next, we need to figure out if the problem is somehow particular to your installation.

make.conf; CFLAGS; modules; ...