path: root/INSTALL
diff options
Diffstat (limited to 'INSTALL')
1 files changed, 36 insertions, 148 deletions
diff --git a/INSTALL b/INSTALL
index c435c06142c2..fe99ffeecde3 100644
@@ -1,166 +1,54 @@
- Version 3.5
+ Version 3.8beta1
William LeFebvre
and a cast of many
-Configuration and installation of top is very straightforward. After
-unpacking the sources, run the script "Configure". It will present you
-with a series of questions, all of which should be explained in the
-presentation. After you have answered all the questions, "Configure" will
-perform all the necessary configuration. Once this is finished, type
-"make install". Make will compile the sources then install the resulting
-executable and manual page in the appropriate places.
+Configuration and installation of top is easy. Top version 3.6
+comes with a configure script generated by gnu autoconf. After
+unpacking the tar file, simply run "./configure". The script will
+automatically perform a series of checks on the system and determine
+what settings are appropriate for the Makefile and certain include
+files. Once configure completes, simply type "make install" and
+top will be compiled and installed. By default, the installation
+location is /usr/local/bin. You can change the destination location
+with the --prefix option to configure.
-The most difficult step in the configuration is the choice of an
-appropriate machine-specific module. The Configure script gives you a
-list of choices complete with brief descriptions of when each choice is
-appropriate. Each module is contained in a separate c file in the
-directory "machine". The module contains all of the machine-specific code
-that makes top work correctly on the architecture in question. All of the
-code in the top-level directory is machine-independent (or at least
-strives to be). Hints for some module choices that are not obvious are
-given at the end of this file.
+In addition to the standard options, top's configure script supports
+the following:
-The first comment in each c file in that directory contains the synopsis
-AND a detailed description of the machines for which that module is
-appropriate. It also contains a list of authors for that module. If you
-are really stumped in this choice, use grep to find your machine
-manufacturer's name or operating system name in machine/*.c. If you still
-can't find one that is appropriate, then chances are very good that one
-hasn't been written yet. If that is the case, then you are out of luck.
+ --with-module=name
+ Force the use of a particular module. Modules are located
+ in the subdirectory "machine". A module's name is derived
+ from the file's basename without the leading "m_".
-If you need to recompile top for a different architecture (that is, using
-a different module) you need to reconfigure top. A short cut is available
-to make this a little easier. If all of your previous answers to the
-configuration questions (except for the module name of course) are
-adequate for the new architecture, then you can just use the command
-"Configure <modulename>". The configuration script will reconfigure top
-using the new module and all the answers you gave last time. It will
-finish with a "make clean". Once that completes, type "make install"
-and make will compile the sources and do the installation.
+ --with-ext=name
+ Compile with the extension "name", found in the subdirectory
+ "ext". At the present time, there are no extensions in the
+ standard distribution.
-By far the most frequently received bug report for top is something like
-this: "We just upgraded our operating system to version and top
-broke. What should we do?" The simple answer is "recompile".
+ --enable-debug
+ --disable-debug
-Top is very sensitive to changes in internal kernel data structures
-(especially the proc and user structures). Some operating systems
-(especially SunOS) are notorious for changing these structure in every
-minor release of the OS. This means that a top executable made under one
-version of the OS will not always work correctly (if even at all) under
-another version. This is just one of those tough facts of life. There is
-really no way around it.
+ Default off. Include debugging output in the compilation,
+ which can be seen with the -D switch.
-To make life even worse, some operating systems (SunOS again) will use
-slightly different proc and user structures on different models. For
-example, "top" built on a SparcStation 2 will not run correctly on a
-SparcStation 10, even if they are both running SunOS 4.1.3. These
-unfortunate circumstances make maintaining top very difficult, especially
-in an environment that runs several different versions of the same
-operating system.
+ --enable-color
+ --disable-color
-But there is hope. If your operating system has a properly functioning
-"uname" command then you can handle this problem rather gracefully.
-Included in the distribution is a shell file called "metatop". All this
-shell file does is:
+ Default on. Include code that allows for the use of color
+ in the output display. Use --disable-color if you do not
+ want this feature compiled in to the code. The configure
+ script also recognizes the spelling "colour".
- exec top-`uname -m`-`uname -r` "$@"
-So when you run this script, it execs a filename that is unique to your
-specific machine architecture and your OS revision number.
-To use "metatop", do the following:
- . on any machine, run Configure and choose the module that is
- appropriate for the machine
- . for all machines which use the same module:
- . group machines according to machine architecture AND OS
- revision number (i.e.: sun4-4.1.1, sun4c-4.1.1, sun4c-4.1.2,
- sun4-4.1.3, sun4c-4.1.3, sun4m-4.1.3, ...)
- . for each group, choose one machine from that group and on it
- run "make clean; make installmeta".
-The "installmeta" rule in the makefile will insure that top is compiled,
-install the shell file "metatop" as "top", then install the executable
-"top" with a name appropriate to the machine architecture and OS revision.
-All versions of Solaris will now work with the module sunos5. Version
-specific modules (such as sunos54) no longer exist.
-First, we need to be speaking the same language:
-sun4 a regular sparc sun 4 architecture machine (sparc station 1,
- sparc station 2, IPC, SLC, etc.)
-sun4m a multiprocessor sparc (Sparc 10, 4/670, 4/690)
-I intended to write the sunos4 module so that an executable compiled on a
-sun4m machine would work correctly on a sun4 machine. Unfortunately my
-experiments indicate that this cannot be done. It turns out that the user
-structure is so different between these two architectures that nothing
-short of a serious hack will make the same executable work correctly on
-both machines. I recommend that you use the separate module "sunos4mp"
-when making an executable for a sun4m architecture, and use "sunos4" when
-making an executable for sun4 or sun4c architectures.
-This is the successor to DECOSF/1. Use the module decosf1.
-If you are running OS/MP version 4.1A, then use the module "osmp4.1a".
-If you are running a version of OS/MP OLDER than 4.1A (that is, one
-of its predecessors), use the module "sunos4".
-If you are running OS/MP 4.1B or LATER, use the module "sunos4mp".
-The module hpux8 works on all version 8 systems. Some say that it works
-with version 9 as well, but one user did send me a separate module for
-version 9. This module has only been tested on series 800 machines. I
-would recommend the following for those running version 9: try hpux9 and
-if it doesn't work then try hpux8. If neither work, then send mail to me
-and/or the modules' authors. Another note: we have a model 730 supposedly
-running version 9.01. The module hpux9 did not compile successfully, but
-the module hpux8 worked fine. The module hpux10 works on all revisions of
-HP/UX 10 except 10.10, where HP removed the definition of the proc structure
-from the system include files.
-If your version of the operating system has patchkit 2.4 installed,
-then you will need to modify machine/m_386bsd.c and uncomment the
-definition of PATCHED_KVM. This patchkit makes what more than a few
-people believe to be a wholly unnecessary patch to the way the kvm
-routines work.
-There is a module for A/UX 3.0 and 3.1. Whether or not it works for
-any other version is not known. Proceed at your own risk.
-Although AUX does not generally have a renice systemcall, it can be
-implemented by tweeking kernel memory. The flag IMPLEMENT_SETPRIORITY
-controls the inclusion of this code. It is off be default. While
-such a simple hack should not be difficult to get right, USE THIS
+ --enable-kill
+ --disable-kill
+ Default on. Include code that allows for renicing and sending
+ signals to processes from within top (the 'kill' and 'renice'
+ commands). Use --disable-kill if you do not want this feature
+ compiled in to the code.