What should I do when the program cannot be compiled? Debug configure

 

Generally, you can only find a very simple "compile Description: Run configure and then run make" in the README file of the software package ". But what should I do if this doesn't work? In this article, Peter Seebash describes how to do this when the automatic configuration script fails-and how to avoid this error as much as possible as a developer. After all, if your program cannot be compiled, the result will be the same as that of your program after compilation, and your users will be reduced.
　　
Many open-source programs now come with configure scripts. One of the purposes of this script is to automatically guess the new system. In the past, the program will attach a Makefile file, which has six different compilation tags and options, but only one will be used, and all others will be commented out with an annotation, tell you to "select the appropriate tag for your system ". If the configuration options are more complex, there may be a long C header file named config. h, which contains some tags to be set, which depends on host system variables.
　　
The first method is simple. Use # ifdef in the code to support two systems, such as BSD and System V. As the Unix type increases, the more practical method is to use # ifdef for each feature. The code for each system is as follows:
　　
Listing 1. code for each system
　　
# Ifdef SUNOS4 | NEXT | NETBSD | FREEBSD | OPENBSD
# Include <string. h>
# Else
# Include <strings. h>
# Endif
　　
The code for each feature is as follows:
　　
Listing 2. code for each feature
　　
# Ifdef HAS_STRING_H
# Include <string. h>
# Else
# Include <strings. h>
# Endif
　　
The latter is easier to adapt to new systems, but developers need to do a lot of work. Because there are too many possible target systems, the second method is of great help to users, not just to automatically generate configuration header files. One way to complete this task is to use the GNU autoconf code to generate the configure script. This script executes the necessary tests and creates a configuration header file with the appropriate values.
　　
Another function of this script is to set predefined variables in a consistent manner. There is always a problem with manually editing the mark, that is, the Makefile file is modified (for example, it is installed in the/usr/gnu instead of the/usr/local directory) but forgot to modify the corresponding value in the header file. Of course, the result is that the compiled programs do not know where to find their own data files. One advantage of using the configure script is that consistent installation can be automatically completed (if the maintainer is correct ).
　　
Developers should note that another benefit of a good configure script is that it allows users to specify personal preferences, such as using/usr/gnu instead of/usr/local.
　　
Finally, the configure script can complete a lot of speculation, that is, the optional software packages installed or the necessary conditions are missing. For example, a program designed to run on X Window System needs to know where X is installed, or even whether X is installed.
　　
How are these possible?
　　
Compile and then compile
　　
Many of configure's function implementation mechanisms are actually very simple. You can design a small test program that can be compiled only when the expected conditions are met. Save it in a temporary file and try to compile it. For example, suppose you want to know whether X wing System is installed in the/usr/X11R6 directory. One way is to do the following test program:
　　
# Include <X11/X. h>
Int main (void) {return 0 ;}
　　
Now, if you use the compiler to try to compile, the compilation will be successful only when <X11/X. h> is in the include path of the compiler. Therefore, for each directory that you think X may be installed, you can add the corresponding directory/include to the include path of the compiler and try to compile the program. If the sample file can be compiled when a value is used, you will get the correct include path.
　　
Note that various test programs have been predefined in autoconf. If possible, use these test programs instead of writing them on your own. This has many benefits. First, the new version of autoconf will improve these test programs and correct their errors. Otherwise, you will have to do the work on your own. Second, this will save you time. Of course, a better way is to completely avoid testing. If you confirm that a test is unnecessary (for example, you still need to set sizeof (char) to 1 even if the machine has more than 8 bytes), you can skip this test at all.
　　
Some tests are functional tests; it is insufficient to determine whether a function named memcmp () exists, and its semantics must be correct. Typically, these tests are used for very insignificant errors that are noticed on one or two platforms. These tests will actually run the test program and check its output. The test program follows the standard Unix habit: if the test passes, the return value is 0. If the test fails, a non-0 value is returned.
　　
Once you have enough test programs, you can use them to automatically determine the required compilation tags and definitions to place them somewhere in the header file. In general, the configure script allows users to give some or all of the known conditions, rather than letting the script guess on its own.
　　
Let's look at a special case. Assume that the system's brokenmemmove () has a problem. If you do not know that it has a bug that only affects a small number of programs, you may compile a program and release it as a product, without realizing that you will encounter accidental catastrophic errors.
　　
In many cases, the final result of a lengthy and complex configure script is as follows: the target system provides every standard feature used by this program, and they work correctly. In this case, why not manually set these tags? This is feasible for developers, but not for many users. Users may not know that their Linux version has specific bugs. They may not know which software packages are installed or where they are installed. Scripts help those who need the most help to complete most of the routine work. When a script error occurs, the extra work may not be too costly.
　　
Where is the error?
　　
Now that you have basically understood what configure has done, you can start looking for errors. There are two possible configure errors. One is that configure is correct, and your system lacks the necessary prerequisites. In most cases, the configure script correctly diagnoses this error. The more troublesome case is the configure's own error. The configuration cannot be generated or an incorrect configuration is generated.
　　
When configure Guesses are correct and you do not have any prerequisites, you must meet the missing prerequisites. After you find and install the script, run the configure script that lacks the prerequisites. (Do not forget to delete the config. cache file, which caches the results of the previous test. You should let configure start from scratch .)
　　
If you are developing a configure script, make sure that the error message you provided is meaningful. If you are testing a function that is part of a common software package that can be added, do not tell the user the name of the function that is missing-tell the user the software package they need. Make sure that the prerequisite information is written to the README file. In addition, please be sure to tell people the version number of other software packages used for testing.
　　
Of course, even after the software is installed as required by the prerequisites, the configure script may still fail to find the newly installed program. In this case, you return to how to do it when configure guesses an error.
　　
Read documents
　　
At any time, when configure fails, you must first run configure-h and check the parameter list. If it cannot find the library you have installed, you may be able to find it in another location. You can also disable and enable some features. For example, the configure script for Angband (A Roguelike game) has an optional flag-enable-gtk, which tells the script to enable GTK support during compilation. Without this flag, you will not try it during compilation.
　　
If your system configuration is strange, you may have to set some very detailed variables for the configure script, and if it is in cross compilation, you may have to do something very special. CC is a variable used by configure to specify the C compiler. Many problems can be solved by specifying the value of CC. If you specify a compiler, configure uses that compiler instead of guessing which one to use. Note that you can specify options and tags in the command line. For example, if you want to support debugging symbols during compilation, try:
　　
CC = "gcc-g-O1"./configure
　　
(Assume that you are using the shell of the sh series. In csh, use setenv to set the environment variable CC .)
　　
Read config. log
　　
When the configure script runs, it creates a file named config. log, which records the test log and the result. For example, a typical config. log segment is as follows:
　　
Listing 3. Typical config. log Content
　　
Configure: 2826: checking for getpwnam in-lsun
Configure: 2853: gcc-o conftest-g-O2-fno-strength-reduce conftest. c-lsun> & 5
Ld: cannot find-lsun
Configure: 2856: $? = 1
Configure: failed program was:
(A listing of the test program follows)
　　
If-lsun in my system should provide getpwnam (), I should be able to use the command line to perform exact checks on it and then use the test program. You only need to perform a small amount of such debugging, and then I can modify the configure script based on the obtained information. Pay attention to the helpful line number; this test starts from line 2,826 of the configure script. (If you are a shell programmer, you may like to print the travel number when reading the configure script snippet; in shell, $ LINENO cannot be automatically expanded to a reasonable value, the script uses sed to create a copy containing a row number !)
　　
When a test fails or an unexpected result is returned, read the log file first. Note that sometimes the test fails only because of the failure of the previous test. This failure is not really important. For example, configure may exit because it cannot find a library you have not heard of, and this may be because the program that fails to test a function in the Standard C library fails to find that library. In this case, you only need to solve the first problem, and the second problem will not appear again.
　　
Testing Programs with bugs
　　
In other cases, configure may occasionally cause a hypothetical error. One scenario is that the test program is incorrectly designed and possible.