home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / bsd_srcs / README < prev    next >
Encoding:
Text File  |  1991-07-01  |  8.1 KB  |  146 lines
  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.
  146.