INSTALL

I have built this tree on NetBSD (i386,sparc), FreeBSD, SunOS, Solaris (sparc,x86). I have also built much of it on Linux, HP-UX, IRIX and Ultrix. Feeback is welcome.

Linux

I've only looked at one Linux system (Red Hat) which may have been very unrepresentative (I'm no judge of Linux distributions), there were no [n]curses headers and no lib[n]curses.so symlink. It also used iostreams for stdio which means libsslfd cannot hook in under stdio - which probably means bftp will not work. I created a symlink for libncurses.so so that stelnetd could compile, but the lack of headers ruled out compiling stn3270 (and probably some of the nifty features in bftp).

The good news is that bmake, SSLeay, SSLr* and stelnet all work fine.

bmake

First unless you are running 4.4BSD, you must build bmake. This tree is designed to be built with bmake and with support for multiple architectures. GNU autoconf is used to generate a config.h which handles most system dependencies, but the Makefiles rely on bmake. Fortunately bmake uses autoconf :-)

If you are running 4.4BSD

You simply need to install my macros in /usr/share/mk, the following command will skip the bsd.*.mk and *.sys.mk files which you should not install on a 4.4BSD system as they will probably break your /usr/src builds:

# cp bmake/mk/[d-s]*.mk /usr/share/mk

Note that as of bmake-3, the macros are in a separate tar file. But we assume that you unpacked mk.tar.gz in bmake's src directory.

Note that FreeBSD's bsd.man.mk adds an extra /man to MANDIR, which is incompatible with our man.mk and most other uses of MANDIR.

Building bmake

As mentioned in bmake, the recommended procedure is now simply:

$ $srcdir/configure --prefix=/usr/local
$ make -f makefile.boot bootstrap
# ./bmake -f Makefile install

Where srcdir is the path to where configure is, or '.'.

$BASE

The Makefiles want to know where the top level directory is. As of bmake version 3, this can be worked out automagically. If using an earlier bmake you should set BASE manually. These Makefiles use my own macro files which are derrived from the NetBSD (1.0?) bsd.*.mk macros, if you are not allowed to install bmake/mk/*.mk in /usr/share/mk or /usr/local/share/mk you can use:

	bmake -m ${BASE}/bmake/mk

Finally, if you do not have the BSD mandoc macros for [nt]roff, or you do not want the man pages formatted, set NOMAN=no in your environment or in Makefile.local.inc

Macro files

A couple of my macro files differ from the bsd.* originals (apart from being more portable), man.mk handles installing unformatted nroff, as well as formatted pages with the normal extension rather than BSD's .0 Unless SUBDIR_MUST_EXIST is defined, subdir.mk will skip missing subdirs (after telling you...) rather than die. This is important, since you very likely have a subset of the full src tree.

Building

In various directories, you may find symlinks named src pointing off to no where. These should point to the directories holding the appropriate distribution. For instance:

$ ls -l ssl/bin/rdist/src
lrwxrwxr-x  1 sjg  wheel  17 Jun 20  1996 ssl/bin/rdist/src@ -> ../../../../rdist-6.1.3
$

Obviously you will need these links correct before you can expect to build things like SSLrdist. See other distributions for details on where to get the other distrbutions you might need.

Now just:

$ cd $BASE
$ bmake obj
$ (cd conf && bmake)
$ bmake depend
$ bmake
# bmake install

mkdep

When you run bmake depend, the macros will use ${MKDEP} (default is /usr/bin/mkdep or /usr/local/share/bin/mkdeps.sh) If you don't have either skip the bmake depend step.

autodep.mk

If you have gcc, you can put .include "autodep.mk" in $BASE/Makefile.local.inc and autodep.mk will automagically update dependencies as and when files are compiled.

obj

Note that I always use obj dirs to keep the build tree neat and facilitate build/editing within emacs while shareing the src via NFS.

WARNING: If you skip the bmake obj step, don't be surprised when the build fails in subtle ways.

The easiest way to use object directories - especially if sharing via read-only NFS mount, is:

$ export MAKEOBJDIRPREFIX=/var/obj
$ bmake obj

bmake will create object directories named $MAKEOBJDIRPREFIX`pwd`, ugly but trivial to setup. Note that MAKEOBJDIRPREFIX must be set in the environment since it is actioned before any Makefiles are read. More on MAKEOBJDIRPREFIX below.

If you want ./obj dirs that are symlinks to a location (per architecture) on the NFS server, the following works:

/usr/local/obj -> src/obj.${MACHINE}

and then I set

BSDSRCDIR=`cd /usr/local/src; /bin/pwd`
BSDOBJDIR=/usr/local/obj

You must set BSDSRCDIR with the same value that /bin/pwd produces as otherwise obj.mk will do the wrong thing.

MAKEOBJDIRPREFIX

I often use:

$ export MAKEOBJDIRPREFIX=/var/obj/sjg
$ bmake obj
$ bmake

The above creates a parallel directory tree under $MAKEOBJDIRPREFIX allowing the src tree to be truely read-only. You must be using bmake version 3 or later, to have everything work correctly. A -current NetBSD make will also work.

MAKEOBJDIR

The neatest setup uses:

$ export MAKEOBJDIR="\${.CURDIR:S,$SRCTOP,$OBJTOP,}"

Where $SRCTOP identifies the top level src directory, and $OBJTOP is the top of the corresponding object tree. With that in the environment, the object directory for $SRCTOP/bin/bmake would be $OBJTOP/bin/bmake which is much neater than say $MAKEOBJDIRPREFIX$SRCTOP/bin/bmake. You can get even fancier, but that's the basic idea.

shared libraries

The lib.mk macros know how to build shared libraries on NetBSD, FreeBSD, SunOS, Solaris, HP-UX and OSF/1. I currently build shared versions of libsslfd as well as SSLeay's libssl and libcrypto.

For other systems lib.mk will use the GNU libtool if you set USE_LIBTOOL=yes though this is a bit more limited.

If you do not want shared libraries built, either set NOPIC in Makefile.local.inc or on the command line, or create .nopic in the src or obj directories concerned.

Alternatively if NOARCHIVE is set you can skip building the archive libraries and use just the shared libs. This can save considerable time on non-development systems.

symlinks

Note that on ELF systems (eg. Solaris, Linux, and recent BSD's) you need to make a symlink like:

# ln -s /usr/local/lib/libsslfd.so.0.3 /usr/lib/libsslfd.so.0

Before the libraries are really usable. ELF systems do not really handle shared lib versioning the way that BSD and SunOS used to do, so we give it just the major version number to look for. Also, in order to link against a shared lib on an ELF you need to create a link like:

# ln -s libsslfd.so.0.3 libsslfd.so

On HP-UX you need to ensure that shared libs are executable!

SSL

The ssl tree here expects SSLeay to be installed in /usr/local/ssl the ssl/build tree can be used to build SSLeay using bmake, just make ssl/build/dist a symlink to the location of the SSLeay srcs, it is currently configured for SSLeay-6.6, build-081 handles SSLeay-0.8.1

Example

An example usually helps. The following assumes that SSLeay has been built and installed.

First unpack all the Quick.com.au packages in a single tree such as /usr/local/src/sjg.

$ mkdir -p /usr/local/src/sjg
$ cd /usr/local/src/sjg
$ gzcat /tmp/bmake.tar.gz | tar xvf -
$ gzcat /tmp/SSLrsh.tar.gz | tar xvf -
..
..

Note that I usually export the src tree read-only so on the build system with /usr/local/src NFS mounted read-only:

$ mkdir /tmp/bmake
$ cd /tmp/bmake
$ /usr/local/src/sjg/bmake/configure --prefix=/usr/local
$ make -f makefile.boot bootstrap
# ./bmake -f Makefile -m /usr/local/src/sjg/bmake/mk install

Now you can return to the main game.

With a clean tree you can just:

$ export MAKEOBJDIRPREFIX=/var/obj
$ cd /usr/local/src/sjg
$ bmake obj
$ bmake

Actually, the first time bmake is invoked it will cause Makefile.base to be created and then tell you to restart make. Also, you will need to be root to install anything as the install macros use chown which is usually restricted to root.

# bmake install

breakage

It is highly likely that your source tree is a small subset of ours. We have taken setps to try and ensure that the build will work for you despite this, but we may have missed something.

In general it is safest to start with a clean tree. If you have unpacked previous versions of SSLrsh.tar you may have Makefiles or headers present that are not in the current release and will cause you problems. If in doubt just:

$ mv /usr/local/src/sjg /usr/local/src/sjg.old
$ mkdir /usr/local/src/sjg
$ ...
$ ...