Single Source code compilation method for advanced programming in UNIX environment

For many new users who are learning advanced programming in the Unix environment (apue), the first problem may be the source code compilation in this book.
. Almost every routine in this book will have such a line of source code
:
# Include "ourhdr. H"
Changed:
# Include "apue. H"

This header file
Yes
The author puts the standard header files commonly used in each routine, some common error handling functions (functions such as ERR _ ** (), and some common macros into a header file. This can be omitted in
A large number of repeated codes are entered in the example, which can reduce the length of each routine. However, this will cause readers a lot of trouble. Because we need to understand how to compile this header file and then compile it into a library file.
Add to our system
. Especially for beginners, I was confident that the result was in compiling the first program.
The problem occurs. I have not figured out how to statically compile "ourhdr. H" into the system.

However, failing to understand how to use the "ourhdr. H" header file does not affect our learning of apue, nor does it affect our compilation and running of every routine. In fact, just think about it.
C programs must be compiled and run smoothly, except for the correct syntax, the most fundamental thing is to ensure that all functions and macros called in our program have a complete source, that is, all calls must be included.
Use the header file of the function and macro. For a specific source program, if we correctly include the header file, the rest is the precautions of the program's original syntax.

How can we determine which header file the system call function is included in? This is not difficult in Unix/Linux systems. Commands in Unix/Linux
Man can help us find it. Man commands not only help us find common commands, but also provide different levels of help, such as system calls or administrator-level commands. For example, Man1 is a user-specific manual in freebsd6.1, MAN 2 is a system call, man 3 is a library function query, and so on ).

Next, we will use the apue program 1-1 (to implement the LS command part of the function ).
)
For example, to illustrate how to adapt the program in the book to all programs that use standard header files. The operating system uses freebsd6.1. After modification, you can refer to the following Unix
I have also compiled and run this program in Debian Linux. The original code of 1-1.c in the book is as follows:

 

# include < sys/ types. h>
# include < dirent. h>
# include "ourhdr.h"

int
main( int argc, char * argv[ ] )
{
    DIR                * dp;
struct dirent    * dirp;

if ( argc ! = 2)
        err_quit( "usage: ls directory_name" ) ;

if ( ( dp = opendir( argv[ 1] ) ) = = NULL )
        err_sys( "can't open %s" , argv[ 1] ) ;
while ( ( dirp = readdir( dp) ) ! = NULL )
        printf ( "%s/n" , dirp- > d_name) ;

    closedir( dp) ;
    exit ( 0) ;
}

The appendix below shows that "ourhdr. H" contains many common header files, some macro definitions, and some common functions and error functions. In fact, for each specific program, we only need to find the header file used in the program.

The system functions used in 1-1.c include: opnedir (), readdir (), printf (), closedir (), and exit ().
The header files of commonly used functions prinft () and exit () are generally known as <stdio. h> and <stdlib. h>. For
Opnedir (), readdir (), and closedir (). We can use man opendir, man readdir, and manclosedir to obtain these three directories.
The header files of the operation function are <sys/types. h> and <dirent. h>. These two header files are also listed in the source program.

 
Second, two functions defined by the author are also used in 1-1.c: err_quit () and err_sys (). These two functions are mainly used for error handling. Of course, use these two
Function processing of error information is complete. However, for our learning, understanding the core functions of a program is the first priority. We can simplify error handling, that is, when an error occurs
Use the printf () function to prompt that an error has occurred. Of course, using printf () for error handling is not a very reasonable method, and we often do not see more critical error messages.
But it is acceptable for us to use it only for learning. After all, the core part we need to understand is the implementation of program functions, and error handling is the second.

With the preceding instructions, we can change 1-1.c to the following:

 

# include < sys/ types. h>
# include < dirent. h>
# include < stdio. h>
# include < stdlib. h>
int main( int argc, char * argv[ ] )
{
    DIR * dp;
struct dirent * dirp;

if ( argc ! = 2)
    {
        printf ( "You need input the directory name./n" ) ;
        exit ( 1) ;   
    }

if ( ( dp = opendir( argv[ 1] ) ) = = NULL )
    {
        printf ( "cannot open %s/n" , argv[ 1] ) ;
        exit ( 1) ;    
    }

while ( ( dirp = readdir( dp) ) ! = NULL )
        printf ( "%s/n" , dirp- > d_name) ;


    closedir( dp) ;

    exit ( 0) ;
}

In this way, the modified program has nothing to do with the author's header file "ourhdr. H" and can be compiled separately. I am using a root user and run the following command:

# GCC 1-1.c // generate the target file a. Out


Or


# Gcc-O 1-1 1-1.c // generate the target file 1-1

No errors or warnings indicate that the compilation is successful. Then we execute the generated target file:

#./A. Out/home


Or


#./1-1/home

All files in the/home path are listed, including directories (.) and (..).

 
In this way, we can basically modify all the routines in this book into programs that do not contain "ourhdr. H. In this way, we can compile each routine separately without having to take into account
. At the same time, this stupid method helps us understand the header files corresponding to different system calls. This should be a good thing for learning.