The uni| X Environment Advanced Programming "source code configuration

Code: http://www.apuebook.com/

Under the second edition, there is a Readme file:

[Email protected]:~/ms/linux/apue/apue.2e# cat README
Read the file called DISCLAIMER.

Some source changes needed to being made after the book went out for the first
Printing. I forgot to make corresponding changes in the source tree on the
System used to develop the book. The changes is summarized below.

1. LIB/RECVFD.C and sockets/recvfd.c-needed sys/uio.h on Mac OS X
2. LIB/SENDFD.C and sockets/sendfd.c-needed Sy S/uio.h on Mac OS X
3. stdio/buf.c-added code for Mac OS X
4. threadctl/suspend.c-changed wait-to-waitloc to AVO ID symbol definition
clash on Solaris
5. Include/apue.h-freebsd compiles work better if we rely on the DEFAULT
system settings. Solaris needed a different Xopen_source definition
and also a cmsg_len definition.

To build the source, edit the make.defines.* file for your system and set
Wkdir to the pathname of the tree containing the source code. Then just
Run "make". It should the system type and build the source for
that platform automatically. If you is running on a system other than
FreeBSD, Linux, Mac OS X, or Solaris, you'll need to modify the makefiles
To include the settings for your system. Also, you'll probably need to
Modify the source code to get it to build on a different operating system.
The example source was compiled and tested using FreeBSD 5.2.1, Linux 2.4.22,
Mac OS X 10.3, and Solaris 9.

For FAQs, updated source code, and the lost chapter, see Http://www.apuebook.com.
Please direct questions, suggestions, and bugs reports to [email protected]

Steve Rago
May 30, 2005

Edit Make.defines

VI Make.defines.linux Modify the variable wkdir, point to the location of your apue source, mine is/home/huangz/code/apue.2e, so

wkdir=/home/huangz/code/apue.2e

4.VI include/apue.h Add a constant Arg_max, which is threadctl/getenv1.c and threadctl/getenv3.c to use; 4096 this value is given in the reference, if there is a problem, modify it yourself.

#define ARG_MAX 4096

5.VI threadctl/getenv1.c Increase

#include "apue.h"

6.VI threadctl/getenv3.c Increase

#include "apue.h"

7.VI threads/badexit2.c modifies the 31st line to convert the return value of Pthread_self () to the int type.

printf ("Thread 2:id is%d\n", (int) pthread_self ());

8.VI std/linux.mk Change two Nawk to gawk

9.make

10.sudo CP Include/apue.h/usr/include

sudo cp lib/libapue.a/usr/lib

Well, test it, remember to use the-LAPUE command to have the compiler link the Apue library

GCC Main.c-lapue

(b) (Another way online)

One of the issues to be addressed here is the problem of source code compilation in the book. In almost every course of this book, there will be a line of source code:
# include "Ourhdr.h"

In the second edition, replace the following:
# include "Apue.h"

This header file is used by the author to put the standard header files that are common in each routine, some commonly used error handling functions (functions such as err_** (), and some commonly used macro definitions to organize in a header file. This eliminates the ability to enter more repetitive code in each routine, which reduces the length of each routine. However, this has brought a lot of trouble to the reader. Because we have to figure out how to compile the header file, and then make the library file and add it to our system. Special reading in the beginner, originally confident, the results in the compilation of the first program when there is a problem. I also did not understand how to put "ourhdr.h" statically compiled into the system.

However, do not understand how to use the "Ourhdr.h" This header file, does not affect our learning apue, also does not affect us to compile and run each routine. In fact, simply think about it, if a C program to be able to compile and run smoothly, in addition to our syntax is correct, and so on, the most fundamental thing is to ensure that our program calls the functions and macros and so on have to have a complete source, that is, must contain all the calling function and the macro is located in the header file. For a specific source program, if we correctly include the header file, then the rest of the program should be aware of the native syntax.

How do you determine if the system call function is included in the header file? This is not a difficult task under the Unix/linux system. Unix/linux Command Man can help us find. The man command not only helps us to find the use of general commands, but also provides different levels of help such as system calls or administrator-level commands, such as FreeBSD6.1, where man 1 is a user-specific manual, man 2 is a system call, Man 3 is a library function query, and so on.

The following is an example of how to adapt a program in a book to a program that uses standard header files in the APUE program 1-1, which implements part of the LS command. Among them, the operating system is FreeBSD6.1, after the corresponding modification can be described in the book in the UNIX system and Linux system running, I also in the Debian Linux successfully compiled and run the program. 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);
}

From the appendix in the back of the book you can see that the content of "Ourhdr.h" is much more, including more common header files, some macro definitions and some common functions and the definition of error functions. In fact, for each specific program, we only need to find the application of the header file can be.

The system function calls used in the 1-1.c are: Opnedir (), Readdir (), printf (), Closedir (), and exit ().
Among them, for the commonly used functions Prinft () and exit (), they are located in the header file is generally known, respectively, is <stdio.h> and <stdlib.h>. For Opnedir (), Readdir () and Closedir (), we can get the three header files for the directory operation with the man Opendir,man Readdir,man Closedir: <sys/ Types.h> and <dirent.h>. These two header files are also listed in the source program.

Secondly, two functions of the author's custom are also used in 1-1.c: Err_quit () and Err_sys (). These two functions are primarily used for error handling. Of course, the use of these two functions for error information processing is relatively perfect. However, as we learn, to understand the core function of the program is the first, we can simplify the error processing, that is, when encountering an error, we simply use the printf () function to indicate that an error occurred. Of course, it is not a reasonable way to use printf () for error handling, and often we do not see more critical error messages, but it is acceptable for us to use them only as a learning option. After all, the core part of our understanding is the function implementation of the program, and the error handling is second.

With the above instructions, we can change the 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);
}

The modified program has no relationship with the author's header file "Ourhdr.h" and can be compiled separately. I am using the root user to execute the command:

# gcc 1-1.c//Generate target file a.out
Or
# Gcc-o 1-1 1-1.c//Generate target file 1-1

There are no errors and warnings stating that the compilation was successful. At this point we execute the generated target file:

#./a.out/home
Or
#./1-1/Home

All files under the/home path are listed, including the directory (.) and (..).

In this way, we can basically modify all the routines in the book to a program that does not contain "ourhdr.h". In this way, we can compile each routine individually without regard to the header file of the hash given by the author. At the same time, this kind of stupid method can help us to understand the corresponding header files of different system calls, which should be a good thing for learning.

Reference: http://blog.csdn.net/think_embed/article/details/8713089

http://blog.csdn.net/xuorui/article/details/5447555

The uni| X Environment Advanced Programming "source code configuration