Category : OS/2 Files
Archive   : KSH48.ZIP
Filename : INSTALL

BUILDING THE PD KSH
===================

The PD KSH can be built in two ways. The default method uses
the POSIX/ANSI compatability libraries in ./std. The
alternative method is to build the ksh in ./sh without the ./std
tree. The second method should be used only if a) you have a
real POSIX environemnt or b) you have major difficulties with
building the ./std tree.

I have modified the source slightly to make standalone building
simpler. Using -DNOSTDHDRS avoids attempts to include ANSI
headers that may be lacking. I have built the shell this way on
all Sun platforms and on a Bull DPX/2 (which has good POSIX
support). The config file defines USE_SIGACT so that the shell
will use the XPG3 signalaction() and friends. You should leave
USE_SIGACT defined, sh/sigact.c contains an implementation for
systems that lack this facility.

It is recommended that you try using the ./std tree first. This
avoids problems like BSD times() calls that do not return an
indication of elapsed time and so on.

Using ./std:
------------

If you are on a Sun building it quite simple:

make CONFIG=-D_BSD

will do it. If you have a sun386 or sun3 and have gcc, it is
worth using, just add CC="gcc -pipe" to the above command line.
If you have SunOS 4.1 or later you probably need to add
-DHAVE_SYS_STDTYPES

Building on other systems may well be more difficult.
Apparently the creating of the ./std/h tree causes problems on
some systems.


Notes on ./std:
---------------

I have updated the Makefiles in ./std/stdc and ./tsd/posix to
maintain the objects within the libraries. Ie.
libstdc.a(strstr.o) If your make(1) doesn't know how to do this
then you will need to modify the makefiles accordingly.

In ReadMe.jrm, John MacMillan recommends being cautious of
std/libstdc.a and using only those routines which your system
lacks. Please note that I have tested virtually none of
./std/stdc. The Makefile contains target lines for most modules
but most are commented out. I suggest you uncomment _only_
those that you need.

On the other hand std/libposix.a seems quite safe, and
indeed provides a better times() call for BSD systems.

Read ReadMe.jrm for more...


Building without ./std:
-----------------------

On some systems it might be worth forgetting about ./std/lib*
either because they proved too difficult to build or they seem
unnecessary. As previously indicated I have done this on Sun's
and on a Bull system. On Sun's it is perhaps not a great idea
as you then get the system's times() call which does not behave
the way the shell wants.

In anycase to build without ./std, you simply cd to ./sh and
either edit the Makefile accordingly, or use an appropriate
command line. For instance:

Sun with SunOS 4.0:

cd ./sh
ln -s ../std/stdc/strstr.c .
ln -s ../std/stdc/memmove.c .
make CFLAGS="-D_BSD -DNOSTDHDRS" \
XOBJS="strstr.o memmove.o" LDLIBS="" LDFLAGS=""

Note that we still need a couple of functions from ./std/stdc

On the Bull system which is a POSIX compliant System V machine:

cd ./sh
make CFLAGS="-D_SYSV" LDLIBS="-lc_s" LDFLAGS=""
make CC=gcc CFLAGS="-D_POSIX_SOURCE" LDLIBS="-lc_s" LDFLAGS=""

INSTALLING:
===========

This is quite simple.

# cp ./ksh /bin
# chmod 555 /bin/ksh

The above assumes of course that you don't already have a
/bin/ksh 🙂
The manual page ksh.1 should be copied to an appropriate
location.
BSD:
# cp ksh.1 /usr/man/man1
SYSV:
# nroff -man ksh.1 > /usr/catman/u_man/man1/ksh.1
# pack /usr/catman/u_man/man1/ksh.1

Or something similar. For systems such as Sun's that really
only ship with a C-shell environment, the ./etc directory
contains a useful /etc/profile and /etc/ksh.kshrc file to
provide a suitable environemnt for /bin/sh and /bin/ksh users,
they should work, they are straight of my system and I use them
on Sun,Bull and even an SCO system.


PROBLEMS:
=========

Clearly building will not be so simple on all systems.
Apparently some of the enum manipulations border on ilegal and
cause some compilers problems. Curiously both gcc -ansi and the
GreenHills compiler on the Bull system are quite picky and did
not complain. Note if you want to use gcc -ansi you may well
need to add some definitions, for instance the following all
work on the sun386:

CC=cc
CC=gcc
CC=gcc -ansi -Dsun -Di386 -Dsun386

The last three items on the last line are normally all defined
automatically, but this is disabled when -ansi is used. The
system headers do not work unless they know what architecture is
in use.

On the Bull DPX/2 I used gcc-2.1, my gcc port will be available
as of release 2.2. To save effort I found it necessary to copy
stdio.h and stdlib.h to gcc's private include directory and edit
them to remove unnecessary #ifdef's and unwanted #include's.

If you find and fix a problem please fill in a copy of
./bug-report and e-mail it to [email protected]

Enjoy!

Simon J. Gerraty