admin/network.2/src.README

This is the src tree for the second Berkeley networking distribution.
This file is intended to be a simple, preliminary guide to finding your
way around and compiling the programs.  We apologize that this
distribution has so little in the way of compatibility with previous
systems.  We had hoped that we could provide compatibility with at least
4.3BSD, but we simply did not have sufficient time to accomplished the
task.

First, there has been a major reorganization of the file system.  (You
may have seen similar reorganizations on systems shipped by Sun
Microsytems and Digital Equipment Corporation, among others.)  In general,
the reorganization is as follows.  (Directories not listed are pretty much
unchanged, i.e.  /dev is the same as always.)

	/etc		configuration files (NO BINARIES)
	/bin		binaries needed when running single-user
	/sbin		binaries for the root user when running single-user

	/var		per machine variable directories
	/var/mail	the old /usr/spool/mail
	/var/spool	the old /usr/spool directories
	/var/tmp	the old /usr/tmp
	/var/acct	the old /usr/adm
	/var/log	log files
	/var/crash	crash dumps

	/usr/bin	the rest of the binaries
	/usr/lib	system libraries (NO BINARIES)
	/usr/libdata	system datafiles
	/usr/libexec	programs executed by other programs
	/usr/sbin	the rest of the binaries for the root user
	/usr/share	architecture independent files

The directories containing the source tree parallel the directories where
the binaries live, i.e. the binaries for /usr/bin are in /usr/src/usr.bin,
the files that are installed in /usr/share/misc live in
/usr/src/share/misc, and so on.  It is our intent that the entire system
be installed from /usr/src -- the files normally found in /etc are
prototyped (and installed) from /usr/src/etc.  Include files are installed
from /usr/src/include.  One exception to this is the software not
maintained at Berkeley.  For example, the Kerberos software can be found
in /usr/src/kerberosIV, and the ISODE software is in
/usr/src/contrib/isode.  Manual pages are in the directories of the
programs that they document; if they aren't directly related to a program,
they are in /usr/src/share/man.

Make has changed a lot.  It's pretty well documented, so you should read
the man page.  All of the makefiles in /usr/src have been modified to use
the new make features.  Your make will almost certainly not work on these
makefiles.  However, the new make will work on your old makefiles.  If
you only wish to install one or two programs, you may want to just create
makefiles for them and build them by hand.  If you want to build the entire
system, you probably want to get our make running on your system.

This is done by by going to usr.bin/src/make and entering "make -f
Makefile.dist".  This is a minimal makefile which just compiles the make
program.  It will create a binary named pmake.  Compiling pmake on your
system may fail.  If it does, there's probably a difference in your
/usr/include files that make is unhappy about.  You probably want to
figure out what the real problem is in this case.  Loading make on your
system may also fail.  If it does, you are probably missing one or more
routines in your C library that make needs.  Finding the correct routine
in the lib/libc/* directories, and creating a .o for the make directory
will probably get you around this problem.

Once you have a "new" make working, you have to install the template files
that it uses.  These files are in the directory src/share/mk.  Normally, they
are installed in the directory /usr/share/mk.  If you wish to install them
somewhere else, change the file pathnames.h in src/usr.bin/make to reflect
where you plan to install them.  There's a file named bsd.README in the
src/share/mk directory that briefly discusses how the BSD make templates
work.  It's not necessary reading, but it might be useful.

Once you have a make compiled and its template files installed, you can use
the standard makefiles.  One other comment, most of the standard makefiles
will attempt to build manual pages as well as the program.  This will be a
problem, because the manual pages require roff macro packages which will not
have been installed.  You can install these macros (see src/share/tmac),
or use the command "make NOMAN=noman" or add NOMAN=man as part of your
"MAKE" environmental variable when you make the BSD source to solve this
problem.

In each of the source directories you will find a symbolic link named "obj".
This symbolic link points to somewhere in the file hierarchy /usr/obj.  For
example, the "obj" symlink in bin/ls points to /usr/obj/bin/ls.  This is the
way that we build multiple architectures from a single source tree.  We
create a /usr/obj that is local to each machine which is building for an
architecture.  Then, we remote mount the source tree (often read-only) and
start the compile.  Make changes directory into the "obj" subdirectory, and
builds the object files there.  (There is one real nastiness in this scheme.
Any makefile wishing to reference a file relative to the source directory
must use the ${.CURDIR} macro before the path name, because when make runs
it cd's into the "obj" directory.  This *will* be corrected by 4.4BSD, but
we haven't done it yet.)  A simple work-around is to remove the symbolic
link obj, or make it a real sub-directory of the source directory.

Now you're ready to try and build the system.  First, we haven't really done
this (as I said before, we just ran out of time).  So don't take the following
as a real solution, it's simply the way that we had planned to approach the
problem.

There are really two problems that you're likely to encounter.  The first
are include files that aren't what the BSD source expects, and the second
are C library routines that are either missing or different.  The include
files are probably best handled by creating a directory, called, for the
sake of discussion, bsdinclude, in the top level of the distribution
source tree.  Add a -I include path to the CFLAGS macro in the source
makefiles that you are trying to compile so that the compiler looks for
its include files in bsdinclude first.  (Another way to do this, to avoid
modifying the makefiles, is to put the -I include path into the
environmental variable "COPTS".  This environmental variable is used by
make.)  Then, as you encounter problems in compiling, create include files
that fix the problem.

For example, one of the changes that we've made in our release is that
we've extracted all full path names from the source code and placed them
either in an include file in the source directory or an include file in
/usr/include.  Therefore, you will find a number of programs that include
<paths.h> (the path include file for the entire system).  Since your
system will probably not have a paths.h include file, you can install the
BSD one in bsdinclude (modifying it as necessary) and the problem should
go away.  However, our <utmp.h> include file has had paths added to it,
as well, and now includes the <lastlog.h> include file as well.  To make
this work, I'd suggest creating a utmp.h file in bsdinclude which #defines
the paths that the BSD utmp.h include file does, but which then includes
your standard utmp.h and lastlog.h include files.  So, the bsdinclude
version of utmp.h might look like:

	#define _PATH_UTMP      "/var/run/utmp"
	#define _PATH_WTMP      "/var/log/wtmp"
	#define _PATH_LASTLOG   "/var/log/lastlog"

	#include "/usr/include/lastlog.h"
	#include "/usr/include/utmp.h"

I believe that this approach will make it possible to build the C library.
Once the C library is built, install it somewhere.  As you compile
programs you will probably find unresolved references that need to be
satisfied using the BSD library.  I'd suggest adding the BSD library
*after* the standard C library.  You can do this by changing the makefiles,
or adding the string "LDADD=-lc the/bsd/library/path" to your environment.
Note, programs that require other libraries will probably require  additional
information in the LDADD environmental variable.