Commit | Line | Data |
---|---|---|
6f3ee4f6 C |
1 | This is the src tree for the second Berkeley networking distribution. |
2 | This file is intended to be a simple, preliminary guide to finding your | |
3 | way around and compiling the programs. We apologize that this | |
4 | distribution has so little in the way of compatibility with previous | |
5 | systems. We had hoped that we could provide compatibility with at least | |
6 | 4.3BSD, but we simply did not have sufficient time to accomplished the | |
7 | task. In general, this release is similar to the 4.3BSD-Reno, although | |
8 | it has a new virtual memory system and other changes. | |
9 | ||
10 | First, there has been a major reorganization of the file system. (You | |
11 | may have seen similar reorganizations on 4.3BSD-Reno and systems shipped | |
12 | by Sun Microsytems and Digital Equipment Corporation, among others.) | |
13 | In general, the reorganization is as follows. (Directories not listed are | |
14 | pretty much unchanged, i.e. /dev is the same as always.) | |
15 | ||
16 | /etc configuration files (NO BINARIES) | |
17 | /bin binaries needed when running single-user | |
18 | /sbin binaries for the root user when running single-user | |
19 | ||
20 | /var per machine variable directories | |
21 | /var/mail the old /usr/spool/mail | |
22 | /var/spool the old /usr/spool directories | |
23 | /var/tmp the old /usr/tmp | |
24 | /var/acct the old /usr/adm | |
25 | /var/log log files | |
26 | /var/crash crash dumps | |
27 | ||
28 | /usr/bin the rest of the binaries | |
29 | /usr/lib system libraries (NO BINARIES) | |
30 | /usr/libdata system datafiles | |
31 | /usr/libexec programs executed by other programs | |
32 | /usr/sbin the rest of the binaries for the root user | |
33 | /usr/share architecture independent files | |
34 | ||
35 | The directories containing the source tree parallel the directories where | |
36 | the binaries live, i.e. the binaries for /usr/bin are in /usr/src/usr.bin, | |
37 | the files that are installed in /usr/share/misc live in | |
38 | /usr/src/share/misc, and so on. It is our intent that the entire system | |
39 | be installed from /usr/src -- the files normally found in /etc are | |
40 | prototyped (and installed) from /usr/src/etc. Include files are installed | |
41 | from /usr/src/include. One exception to this is the software not | |
42 | maintained at Berkeley. For example, the Kerberos software can be found | |
43 | in /usr/src/kerberosIV, and the ISODE software is in | |
44 | /usr/src/contrib/isode. Manual pages are in the directories of the | |
45 | programs that they document; if they aren't directly related to a program, | |
46 | they are in /usr/src/share/man. | |
47 | ||
48 | Make has changed a lot. It's pretty well documented, so you should read | |
49 | the man page. All of the makefiles in /usr/src have been modified to use | |
50 | the new make features. Your make will almost certainly not work on these | |
51 | makefiles. However, the new make will work on your old makefiles. If | |
52 | you only wish to install one or two programs, you may want to just create | |
53 | makefiles for them and build them by hand. If you want to build the entire | |
54 | system, you probably want to get our make running on your system. | |
55 | ||
56 | This is done by by going to usr.bin/src/make and entering "make -f | |
57 | Makefile.dist". This is a minimal makefile which just compiles the make | |
58 | program. It will create a binary named pmake. Compiling pmake on your | |
59 | system may fail. If it does, there's probably a difference in your | |
60 | /usr/include files that make is unhappy about. You probably want to | |
61 | figure out what the real problem is in this case. Loading make on your | |
62 | system may also fail. If it does, you are probably missing one or more | |
63 | routines in your C library that make needs. Finding the correct routine | |
64 | in the lib/libc/* directories, and creating a .o for the make directory | |
65 | will probably get you around this problem. Once pmake compile and loads, | |
66 | it can be installed as "make". | |
67 | ||
68 | Once you have a "new" make working, you have to install the template files | |
69 | that it uses. These files are in the directory src/share/mk. Normally, they | |
70 | are installed in the directory /usr/share/mk. If you wish to install them | |
71 | somewhere else, change the file pathnames.h in src/usr.bin/make to reflect | |
72 | where you plan to install them. There's a file named bsd.README in the | |
73 | src/share/mk directory that briefly discusses how the BSD make templates | |
74 | work. It's not necessary reading, but it might be useful. | |
75 | ||
76 | Once you have a make compiled and its template files installed, you can use | |
77 | the standard makefiles. One other comment, most of the standard makefiles | |
78 | will attempt to build manual pages as well as the program. This will be a | |
79 | problem, because the manual pages require roff macro packages which will not | |
80 | have been installed. You can install these macros (see src/share/tmac), | |
81 | or use the command "make NOMAN=noman" or add NOMAN=man as part of your | |
82 | "MAKE" environmental variable when you make the BSD source to solve this | |
83 | problem. | |
84 | ||
85 | In each of the source directories you will find a symbolic link named "obj". | |
86 | This symbolic link points to somewhere in the file hierarchy /usr/obj. For | |
87 | example, the "obj" symlink in bin/ls points to /usr/obj/bin/ls. This is the | |
88 | way that we build multiple architectures from a single source tree. We | |
89 | create a /usr/obj that is local to each machine which is building for an | |
90 | architecture. Then, we remote mount the source tree (often read-only) and | |
91 | start the compile. Make changes directory into the "obj" subdirectory, and | |
92 | builds the object files there. (There is one real nastiness in this scheme. | |
93 | Any makefile wishing to reference a file relative to the source directory | |
94 | must use the ${.CURDIR} macro before the path name, because when make runs | |
95 | it cd's into the "obj" directory. This *will* be corrected by 4.4BSD, but | |
96 | we haven't done it yet.) A simple work-around is to remove the symbolic | |
97 | link obj, or make it a real sub-directory of the source directory. | |
98 | ||
99 | Now you're ready to try and build the system. First, we haven't really done | |
100 | this (as I said before, we just ran out of time). So don't take the following | |
101 | as a real solution, it's simply the way that we had planned to approach the | |
102 | problem. | |
103 | ||
104 | There are really two problems that you're likely to encounter. The first | |
105 | are include files that aren't what the BSD source expects, and the second | |
106 | are C library routines that are either missing or different. The include | |
107 | files are probably best handled by creating a directory, called, for the | |
108 | sake of discussion, bsdinclude, in the top level of the distribution | |
109 | source tree. Add a -I include path to the CFLAGS macro in the source | |
110 | makefiles that you are trying to compile so that the compiler looks for | |
111 | its include files in bsdinclude first. (Another way to do this, to avoid | |
112 | modifying the makefiles, is to put the -I include path into the | |
113 | environmental variable "COPTS". This environmental variable is used by | |
114 | make.) Then, as you encounter problems in compiling, create include files | |
115 | that fix the problem. | |
116 | ||
117 | For example, one of the changes that we've made in our release is that | |
118 | we've extracted all full path names from the source code and placed them | |
119 | either in an include file in the source directory or an include file in | |
120 | /usr/include. Therefore, you will find a number of programs that include | |
121 | <paths.h> (the path include file for the entire system). Since your | |
122 | system will probably not have a paths.h include file, you can install the | |
123 | BSD one in bsdinclude (modifying it as necessary) and the problem should | |
124 | go away. However, our <utmp.h> include file has had paths added to it, | |
125 | as well, and now includes the <lastlog.h> include file as well. To make | |
126 | this work, I'd suggest creating a utmp.h file in bsdinclude which #defines | |
127 | the paths that the BSD utmp.h include file does, but which then includes | |
128 | your standard utmp.h and lastlog.h include files. So, the bsdinclude | |
129 | version of utmp.h might look like: | |
130 | ||
131 | #define _PATH_UTMP "/var/run/utmp" | |
132 | #define _PATH_WTMP "/var/log/wtmp" | |
133 | #define _PATH_LASTLOG "/var/log/lastlog" | |
134 | ||
135 | #include "/usr/include/lastlog.h" | |
136 | #include "/usr/include/utmp.h" | |
137 | ||
138 | I believe that this approach will make it possible to build the C library. | |
139 | Once the C library is built, install it somewhere. As you compile | |
140 | programs you will probably find unresolved references that need to be | |
141 | satisfied using the BSD library. I'd suggest adding the BSD library | |
142 | *after* the standard C library. You can do this by changing the makefiles, | |
143 | or adding the string "LDADD=-lc the/bsd/library/path" to your environment. | |
144 | Note, programs that require other libraries will probably require additional | |
145 | information in the LDADD environmental variable. |