NSPR: Build System and Supported Platforms
Note: This was written in 1998. Platforms and releases have changed since then. See the release notes for current data.
NSPR has been implemented on over 20 platforms. A platform may have
more than one implementation strategy of its multi threading and I/O facilities.
This article explains the NSPR build system and how to specify a particular
implementation strategy, compiler or compiler switches, or the target OS
for your build on each platform.
Implementation Strategies
Threads are at the core of NSPR, and the I/O functions are tied to the multi threading facilities because many I/O functions may block the calling threads. NSPR has multiple implementation strategies of its multi threading and I/O functions. The various implementation strategies can be organized into the hierarchy below:- Classic NSPR (This is our first code base, hence the term "classic NSPR"):
- Local threads only: All threads are user-level threads implemented by NSPR.
- Global threads only: All threads are native threads supplied by the OS vendor. For example, Solaris UI (Unix International) threads and Win32 threads.
- Combined: NSPR multiplexes user-level threads on top of native, kernel-level threads. This is also called the MxN model. At present, there are three implementations of the combined model.
- IRIX: sprocs + NSPR user-level threads
- Windows NT: Win32 threads + NT fibers
- Pthreads-user: kernel-level pthreads + NSPR user-level threads
- Pthreads: All threads are pthreads. The relevant code is in mozilla/nsprpub/pr/src/pthreads (threads and I/O).
- Classic NSPR: mozilla/nsprpub/pr/src/threads/combined (threads), mozilla/nsprpub/pr/src/io (I/O)
- Pthreads: mozilla/nsprpub/pr/src/pthreads (threads and I/O)
Compilers
For ease of integration with third-party libraries, which may use native threads, NSPR uses the native threads whenever possible. As a result, native compilers are used to build NSPR on most platforms because they have better debugging support for native threads. The only exception is Solaris, where both cc and gcc are used.NSPR Build System
On Unix and Win32, NSPR build system is based on GNU make. (GNU make can be obtained by anonymous ftp from ftp://prep.ai.mit.edu/pub/gnu/.) On Mac, NSPR uses Metrowork's CodeWarrior Mac project files.Inside Netscape, we use GNU make 3.74 on Unix, but our makefiles should work fine under newer versions of GNU make. On Win32, we use an internal Win32 port of GNU make 3.74 and a homegrown stripped-down version of Bourne shell called shmsdos.exe. Our own Win32 port of GNU make and shmsdos.exe are distributed with the NSPR source. Our makefiles also work under the official Win32 port of GNU make (3.75 and above) and the Korn shell sh.exe in MKS Toolkit.
Every directory in NSPR has a makefile named Makefile, which includes the makefile fragments in mozilla/nsprpub/config. NSPR makefiles implement the common Netscape makefile targets such as export, libs, and install. However, some makefiles targets are no-op in NSPR because they are not necessary for NSPR.
To build NSPR, change directory to the root of our source tree
cd mozilla/nsprpub
and then issue the command
gmake
Make will recursively go into all the subdirectories and the right
things will happen.
The table below lists the common NSPR makefile targets.
| all | The default target. Same as export libs install. |
| export | Do a complete build. |
| libs | No-op. |
| install | No-op. |
| depend | No-op. This means that NSPR makefiles do not have header file dependencies. |
| clean | Remove .o files. |
| clobber | Remove .o files, libraries, and executable programs. |
| realclean | Remove all generated files and directories. |
| clobber_all | Same as realclean. |
The table below lists common makefile variables that one can specify
on the command line to customize a build..
| BUILD_OPT | Optimized build (default: debug build). |
| OS_TARGET | Set to the target OS (WIN95 or WIN16) when doing cross-compilation on NT (default: same as the host OS). |
| NS_USE_GCC | Use gcc and g++ (default: native compilers). |
| USE_PTHREADS | Build pthreads version. |
| CLASSIC_NSPR | Build classic NSPR version (usually local threads only). |
| PTHREADS_USER | Build pthreads-user version. |
| LOCAL_THREADS_ONLY | Build local threads only version. |
| USE_DEBUG_RTL | On Win32, compile with /MDd in the debug build (default: /MD). Optimized build always uses /MD. |
| USE_N32 | On IRIX, compile with -n32 (default: -32). |
| USE_IPV6 | Enable IPv6. |
| MOZILLA_CLIENT | Adjust NSPR build system for Netscape Client (mozilla). |
Platforms
Platforms supported by NSPR can be divided into three categories: Unix, Windows, and Mac. At present, NSPR aims to support Netscape Communicator 5.0 and Server Suitespot 4.0. The platforms on which we build our binary releases are listed below.Unix
AIX: 4.2.1- The default implementation strategy is pthreads. Local threads only
and pthreads-user versions are also available. To build the local threads
only version, use the command
gmake CLASSIC_NSPR=1
To build the pthreads-user version, use the command
gmake PTHREADS_USER=1
- The default implementation strategy is local threads only.
- The default implementation strategy is pthreads. To build the local
threads only version, use the command
gmake CLASSIC_NSPR=1
- The default implementation strategy is local threads only.
- The default implementation strategy is pthreads, or rather DCE threads
(Posix thread draft 4). To build the local threads only version, use the
command
gmake CLASSIC_NSPR=1
- The default implementation strategy is pthreads. Local threads only
and pthreads-user versions are also available. To build the local threads
only version, use the command
gmake CLASSIC_NSPR=1
To build the pthreads-user version, use the command
gmake PTHREADS_USER=1
- The default implementation strategy is combined (MxN). A global thread
is mapped to an Irix sproc. Local threads are implemented using user-level
context switching in NSPR. The primordial thread, which executes the main()
function, is a local thread.
The pthreads version is also available. To build the pthreads version, use the command
gmake USE_PTHREADS=1
- The default implementation strategy is local threads only. The pthreads
version, based on LinuxThreads, is mostly working. To build the pthreads
version, use the command
gmake USE_PTHREADS=1
- The default implementation strategy is local threads only.
- The default implementation strategy is local threads only.
- The default implementation strategy is local threads only.
- The default implementation strategy is local threads only.
- The default implementation strategy is local threads only.
- The default implementation strategy is global threads only, in which
every NSPR thread is mapped to a native Solaris UI thread. Local threads
only and pthreads versions are also available. To build the local threads
only version, use the command
gmake LOCAL_THREADS_ONLY=1
To build the pthreads version, use the command
gmake USE_PTHREADS=1
To build with gcc and g++, use the command
gmake NS_USE_GCC=1
- The default implementation strategy is local threads only.
- The default implementation strategy is local threads only.
Windows
Windows NT: 3.51, 4.0, Windows 2000- The default implementation strategy is combined (MxN). A global thread
is mapped to a Win32 native thread. A local thread is an NT fiber. The
primordial thread, which executes main(), is a local thread.
NSPR requires NT 3.51 Service Pack 5 or NT 4.0 Service Pack 3. The service packs can be downloaded from Microsoft's ftp site at ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa.
- The default implementation strategy is global threads only. Note that
the Windows 9x binary is the generic Win32 binary that runs on both Windows
9x and NT.
Windows 9x version of NSPR can be built on an NT machine with the command
gmake OS_TARGET=WIN95
- The default implementation strategy is local threads only. Windows
3.1 version of NSPR can be built on an NT machine with the command
gmake OS_TARGET=WIN16
Mac
- The default implementation strategy is local threads only.
Last updated: Thu Dec 17 12:14:45 PST
1998