libtiff: Strip out antique instructions about unsupported build targets.

From 24d28ba90da87acd63db9c0298391153d375dda9 Mon Sep 17 00:00:00 2001
From: Bob Friesenhahn <[EMAIL REDACTED]>
Date: Sat, 18 Feb 2012 21:36:51 +0000
Subject: [PATCH] Strip out antique instructions about unsupported build

 html/build.html | 512 ++++++++----------------------------------------
 1 file changed, 78 insertions(+), 434 deletions(-)

diff --git a/html/build.html b/html/build.html
index 1e2c2596..7f583469 100644
--- a/html/build.html
+++ b/html/build.html
@@ -2,7 +2,7 @@
 <meta name="generator" content=
-"HTML Tidy for Solaris (vers 12 April 2005), see">
+"HTML Tidy for Linux (vers 25 March 2009), see">
 <title>Building the TIFF Software Distribution</title>
 <body bgcolor="white">
@@ -11,15 +11,8 @@ <h1><font face="Arial, Helvetica, Sans"><img src=
 "1" hspace="6"> Building the Software Distribution</font></h1>
 <li><a href="#UNIX">Building on a UNIX system</a>.</li>
-<li><a href="#MacMPW">Building on a Macintosh system with
-<li><a href="#MacCW">Building on a Macintosh system with
 <li><a href="#PC">Building on an MS-DOS or Windows system</a>.</li>
-<li><a href="#DJGPP">Building on MS-DOS with the DJGPP v2
 <li><a href="#VMS">Building on a VMS system</a>.</li>
-<li><a href="#Acorn">Building on an Acorn RISC OS system</a>.</li>
 <li><a href="#Other">Building the Software on Other
@@ -27,9 +20,9 @@ <h1><font face="Arial, Helvetica, Sans"><img src=
 This chapter contains step-by-step instructions on how to configure
 and build the TIFF software distribution. The software is most
 easily built on a UNIX system, but with a little bit of work it can
-easily be built and used on other non-UNIX platforms. <a name=
-"UNIX" id="UNIX"></a>
+easily be built and used on other non-UNIX platforms.
+<a name="UNIX" id="UNIX"></a>
 <h2>Building on a UNIX System</h2>
 To build the software on a UNIX system you need to first run the
 configure shell script that is located in the top level of the
@@ -40,25 +33,23 @@ <h2>Building on a UNIX System</h2>
 and then <tt>make install</tt> to do the installation; for example:
 <div style="margin-left: 2em">
-hyla% <b>cd tiff-v3.4beta099</b>
+hyla% <b>cd ./tiff-4.0.0</b>
 hyla% <b>./configure</b>
     <i>...lots of messages...</i>
 hyla% <b>make</b>
     <i>...lots of messages...</i>
+hyla% <b>make check</b>
+    <i>...lots of messages...</i>
 hyla# <b>make install</b>
-Supplied makefiles are depend on GNU <tt>make</tt> utility, so you
-will need the one. Depending on your installation <b>make</b>
-command may invoke standard system <tt>make</tt> and <b>gmake</b>
-invoke GNU make. In this case you should use former. If you don't
-have <tt>make</tt> at all, but only <tt>gmake</tt>, you should
-export environment variable <tt>MAKE=gmake</tt> before
+Supplied makefiles are dependent on a <tt>make</tt> utility and a C
+(and optionally a C++ compiler), so you will need these tools.
 <p>In general, the software is designed such that the following
 should be ``<i>make-able</i>'' in each directory:</p>
 <div style="margin-left: 2em">
 make [all]      build stuff
+make check      run the test suite
 make install    build&amp;install stuff
 make clean      remove .o files, executables and cruft
 make distclean  remove everything, that can be recreated
@@ -75,28 +66,34 @@ <h3>Build Trees</h3>
 directories as the source code.
 <div style="margin-left: 2em">
-hyla% <b>cd tiff-v3.4beta099</b>
-hyla% <b>ls</b>
-COPYRIGHT       VERSION         config.sub      dist            man     config.guess    configure       html            port
-README     contrib         libtiff         tools
+hyla% <b>gzip -dc tiff-4.0.0.tar.gz | tar -xf -</b>
+hyla% <b>cd ./tiff-4.0.0</b>
 hyla% <b>./configure</b>
+hyla% <b>make</b>
+hyla% <b>make check</b>
+hyla% <b>make install</b>
 <p>Otherwise, you can configure a build tree that is parallel to
-the source tree hierarchy but which contains only configured files
-and files created during the build procedure.</p>
+the source tree hierarchy (or in some completely different place)
+but which contains only configured files and files created during
+the build procedure.</p>
 <div style="margin-left: 2em">
-hyla% <b>cd tiff-v3.4beta099</b>
-hyla% <b>mkdir obj obj/mycpu</b>
-hyla% <b>cd obj/mycpu</b>
-hyla% <b>../../configure</b>
+hyla% <b>gzip -dc tiff-4.0.0.tar.gz | tar -xf -</b>
+hyla% <b>mkdir tiff-4.0.0-build</b>
+hyla% <b>cd ./tiff-4.0.0-build</b>
+hyla% <b>../tiff-4.0.0/configure</b>
+hyla% <b>make</b>
+hyla% <b>make check</b>
+hyla% <b>make install</b>
 This second scheme is useful for:
 <li>building multiple targets from a single source tree</li>
 <li>building from a read-only source tree (e.g. if you receive the
 distribution on CD-ROM)</li>
+<li>sharing the source files via a network, but building on
+multiple systems</li>
 <a name="ConfigOptions" id="ConfigOptions"></a>
 <hr width="65%" align="right">
@@ -117,8 +114,8 @@ <h3>Configuration Options</h3>
 the software is installed in the <b>/usr/local</b> hierarchy. To
 change this behaviour the appropriate parameters can be specified
 on the command line to configure. Run <b>./configure --help</b> to
-get a list of possible options. Installation related options are
-shown below.</p>
+get a full list of possible options. Standard installation related
+options are shown below.</p>
 Installation directories:
@@ -135,18 +132,21 @@ <h3>Configuration Options</h3>
 For better control, use the options below.
 Fine tuning of the installation directories:
-  --bindir=DIR           user executables [EPREFIX/bin]
-  --sbindir=DIR          system admin executables [EPREFIX/sbin]
-  --libexecdir=DIR       program executables [EPREFIX/libexec]
-  --datadir=DIR          read-only architecture-independent data [PREFIX/share]
-  --sysconfdir=DIR       read-only single-machine data [PREFIX/etc]
-  --sharedstatedir=DIR   modifiable architecture-independent data [PREFIX/com]
-  --localstatedir=DIR    modifiable single-machine data [PREFIX/var]
-  --libdir=DIR           object code libraries [EPREFIX/lib]
-  --includedir=DIR       C header files [PREFIX/include]
-  --oldincludedir=DIR    C header files for non-gcc [/usr/include]
-  --infodir=DIR          info documentation [PREFIX/info]
-  --mandir=DIR           man documentation [PREFIX/man]
+  --bindir=DIR            user executables [EPREFIX/bin]
+  --sbindir=DIR           system admin executables [EPREFIX/sbin]
+  --libexecdir=DIR        program executables [EPREFIX/libexec]
+  --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
+  --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
+  --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
+  --libdir=DIR            object code libraries [EPREFIX/lib]
+  --includedir=DIR        C header files [PREFIX/include]
+  --oldincludedir=DIR     C header files for non-gcc [/usr/include]
+  --datarootdir=DIR       read-only arch.-independent data root [PREFIX/share]
+  --datadir=DIR           read-only architecture-independent data [DATAROOTDIR]
+  --localedir=DIR         locale-dependent data [DATAROOTDIR/locale]
+  --mandir=DIR            man documentation [DATAROOTDIR/man]
+  --docdir=DIR            documentation root [DATAROOTDIR/doc/tiff]
+  --htmldir=DIR           html documentation [DOCDIR]
 Program names:
   --program-prefix=PREFIX            prepend PREFIX to installed program names
@@ -173,10 +173,17 @@ <h3>Configuring Optional Packages/Support</h3>
 users of the TIFF software. If shared libarries are not used then
 the code is statically linked into each application that uses it.
 By default both types of binaries is configured.</p>
-<p><tt>--enable-rpath&nbsp;&nbsp;&nbsp;&nbsp;Enable runtime linker
-paths (-R libtool option)</tt></p>
+runtime linker paths (-R libtool option)</tt></p>
 <p>Add library directories (see other options below) to the TIFF
 library run-time linker path.</p>
+<p><tt>--enable-ld-version-script&nbsp;&nbsp;Enable linker version
+script (default is disabled)</tt></p>
+<p>Add shared library symbol versioning on ELF-based systems (e.g.
+Linux and FreeBSD) which use the GNU linker. This is needed if
+several major versions of libtiff might be loaded at once into the
+same program.</p>
 <dt><i>JPEG Support</i></dt>
 <dd><tt>--disable-jpeg&nbsp;&nbsp;&nbsp;&nbsp;disable IJG JPEG
@@ -189,245 +196,25 @@ <h3>Configuring Optional Packages/Support</h3>
 TIFF images with JPEG-encoded data. Support for JPEG-encoded data
 requires the Independent JPEG Group (IJG) <tt>libjpeg</tt>
 distribution; this software is available at <a href=
-<b>configure</b> script automatically tries to search the working
-IJG JPEG installation. If it fails to find library, JPEG support
-will be automatically disabled.If you want specify the exact paths
-to library binary and headers, use above switches for that.</dd>
+""></a>. <b>configure</b>
+script automatically tries to search for a working IJG JPEG
+installation. If it fails to find library, JPEG support will be
+automatically disabled.If you want specify the exact paths to
+library binary and headers, use above switches for that.</dd>
 <dt><i>ZIP Support</i></dt>
 <dd>The <tt>ZIP</tt> support enables support for the handling of
 TIFF images with deflate-encoded data. Support for deflate-encoded
 data requires the freely available <tt>zlib</tt> distribution
 written by Jean-loup Gailly and Mark Adler; this software is
 available at <a href=
-(or try <a href=
-If ZIP support is enabled the <tt>DIRS_LIBINC</tt> and
-<tt>DIR_GZLIB</tt> parameters should also be set (see below). By
-default this package is not configured.</dd>
+""></a>. If ZIP support is
+enabled the <tt>DIRS_LIBINC</tt> and <tt>DIR_GZLIB</tt> parameters
+should also be set (see below). By default this package is not
 <a name="Sample" id="Sample"></a>
 <hr width="65%" align="right">
-<h3>A Sample Configuration Session</h3>
-This section shows a sample configuration session and describes the
-work done. The session is shown indented in a <tt>fixed width
-font</tt> with user-supplied input in a <tt><b>bold font</b></tt>.
-Comments are shown in a normal or <i>italic</i> font. This session
-was collected on a 486 machine running BSDI 1.1.
-<div style="margin-left: 2em">
-wullbrandt% <b>mkdir tiff</b>
-wullbrandt% <b>cd tiff</b>
-wullbrandt% <b>ln -s /hosts/oxford/usr/people/sam/tiff src</b>
-A build tree separate from the source tree is used here. In fact,
-in this case the distribution is accessed from a read-only
-NFS-mounted filesystem.
-<div style="margin-left: 2em">
-wullbrandt% <b>src/configure</b>
-Configuring TIFF Software v3.4beta015.
-Reading site-wide parameters from ../tiff-v3.4beta015/
-Reading local parameters from config.local.
-Gosh, aren't you lucky to have a i386-unknown-bsdi1.1 system!
-Note that configure announces the distribution version and the
-deduced target configuration (<tt>i386-unknown-bsdi1.1</tt> here).
-<div style="margin-left: 2em">
-Using /usr/local/bin/gcc for a C compiler (set CC to override).
-Looks like /usr/local/bin/gcc supports the -g option.
-Using " -g" for C compiler options.
-configure checked the normal shell search path for potential ANSI C
-compilers. The compiler is selected according to it properly
-compiling a small ANSI C test program. A specific compiler may be
-requested by setting the <tt>CC</tt> environment variable to the
-appropriate pathname, by supplying the parameter on the command
-line, e.g. <tt>-with-CC=gcc</tt>, or by setting <tt>CC</tt> in a
-configuration file.
-<p><img src="images/info.gif" align="left" hspace="10"> <em>Note
-that an ANSI C compiler is required to build the software. If a C
-compiler requires options to enable ANSI C compilation, they can be
-specified with the <tt>ENVOPTS</tt> parameter.</em></p>
-<p>Once a compiler is selected configure checks to see if the
-compiler accepts a -g option to enable the generation of debugging
-symbols, and if the compiler includes an ANSI C preprocessor.</p>
-<div style="margin-left: 2em">
-Using /usr/ucb/make to configure the software.
-Next various system-specific libraries that may or may not be
-needed are checked for (none are needed in this case). If your
-system requires a library that is not automatically included it can
-be specified by setting the <tt>MACHDEPLIBS</tt> parameter.
-<p><i>Creating port.h.</i> The <b>port.h</b> file is included by
-all the C code in the library (but not the tools). It includes
-definitions for functions and type definitions that are missing
-from system include files, <tt>#defines</tt> to enable or disable
-system-specific functionality, and other odds and ends.</p>
-<div style="margin-left: 2em">
-Creating libtiff/port.h with necessary definitions.
-... using LSB2MSB bit order for your i386 cpu
-... using big-endian byte order for your i386 cpu
-... configure use of mmap for memory-mapped files
-... O_RDONLY is in &lt;fcntl.h&gt;
-... using double for promoted floating point parameters
-... enabling use of inline functions
-Done creating libtiff/port.h.
-This file can take a long time to create so configure generates the
-file only when it is needed, either because the file does not exist
-or because a different target or compiler is to be used. Note that
-running "<tt>make distclean</tt>" in the top-level directory of the
-build tree will remove the <b>port.h</b> file (along with all the
-other files generated by configure).
-<p><i>Selecting emulated library functions.</i> Certain library
-functions used by the tools are not present on all systems and can
-be emulated using other system functionality. configure checks for
-the presence of such functions and if they are missing, will
-configure emulation code from the <b>port</b> directory to use
-instead. Building the TIFF software on unsupported systems may
-require adding to the code to the <b>port</b> directory.</p>
-<div style="margin-left: 2em">
-Checking system libraries for functionality to emulate.
-Done checking system libraries.
-If a routine must be emulated and configure does not automatically
-check for it, the routine name can be specified using the
-<tt>PORTFUNCS</tt> parameter. To add emulation support for a new
-function <tt>foo</tt>, create a file <b>port/foo.c</b> that
-contains the emulation code and then set <tt>PORTFUNCS=foo</tt> in
-a configuration file or modify the configure script to
-automatically check for the missing function.
-<div style="margin-left: 2em">
-Checking for Dynamic Shared Object (DSO) support.
-Done checking for DSO support.
-If the <tt>DSO</tt> package is enabled (<tt>DSO=auto</tt> or
-<tt>DSO=yes</tt>), then configure will verify the system and
-compiler are capable of constructing SVR4-style DSO's in the
-expected way. Note that while a system may support DSO's the
-compiler may not be capable of generating the required
-position-independent code and/or the compiler may not pass the
-needed options through to the loader.
-<p><i>Selecting utility programs.</i> configure locates various
-system utility programs that are used during installation of the
-<div style="margin-left: 2em">
-Selecting programs used during installation.
-Looks like mv supports the -f option to force a move.
-Looks like /bin/ln supports the -s option to create a symbolic link.
-Done selecting programs.
-<p><i>Selecting default configuration parameters.</i> The remainder
-of the work done by configure involves setting up configuration
-parameters that control the placement and setup of files during the
-installation procedure.</p>
-<div style="margin-left: 2em">
-Selecting default TIFF configuration parameters.
-Looks like manual pages go in /usr/contrib/man.
-Looks like manual pages should be installed with bsd-nroff-gzip-0.gz.
-TIFF configuration parameters are:
-[ 1] Directory for tools:               /usr/contrib/bin
-[ 2] Directory for libraries:           /usr/contrib/lib
-[ 3] Directory for include files:       /usr/contrib/include
-[ 4] Directory for manual pages:        /usr/contrib/man
-[ 5] Manual page installation scheme:   bsd-nroff-gzip-0.gz
-Are these ok [yes]? 
-At this point you can interactively modify any of the displayed
-parameters. Hitting a carriage return or typing <tt>yes</tt> will
-accept the current parameters. Typing one of the number displayed
-along the left hand side causes configure to prompt for a new value
-of the specified parameter. Typing anything else causes configure
-to prompt for a new value <em>for each parameter</em>. In general
-hitting carriage return will accept the current value and typing
-anything that is unacceptable will cause a help message to be
-displayed. A description of each of the configuration parameters is
-given below.
-<p>Once acceptable parameters are setup configure will generate all
-the files that depend on these parameters. Note that certain files
-may or may not be created based on the configuration of optional
-packages and/or the functions supported by target system.</p>
-<div style="margin-left: 2em">
-Creating Makefile from ../tiff-v3.4beta015/
-Creating libtiff/Makefile from ../tiff-v3.4beta015/libtiff/
-Creating man/Makefile from ../tiff-v3.4beta015/man/
-Creating tools/Makefile from ../tiff-v3.4beta015/tools/
-Creating port/ from ../tiff-v3.4beta015/port/
-<a name="DSOSupport" id="DSOSupport"></a>
-<h3>Shared Library Support</h3>
-It is desirable to make the TIFF library be a shared object on
-systems that have support for shared libraries. Unfortunately the
-rules to use to build a shared library vary between operating
-systems and even compilers. The distributed software includes
-support for building a shared version of the library on a number of
-different systems. This support is split between rules in the file
-<b>libtiff/</b> that construct the shared library and
-checks done by the <tt>configure</tt> script to verify that the
-expected rules are supported by compilation tools for the target
-<p>To add new support for building a shared library both these
-files must be updated. In the configure script search for the
-section where the autoconfiguration setting of the <tt>DSO</tt>
-parameter is handled and add a new case for the target system that
-sets the <tt>DSOSUF</tt>, <tt>DSOLD</tt>, <tt>DSOOPTS</tt>, and
-<tt>LIBCOPTS</tt> options as appropriate for the system.
-<tt>DSOSUF</tt> specifies the filename suffix used for the shared
-library (e.g. ``.so'' for Dynamic Shared Objects on most SVR4-based
-systems). <tt>DSOLD</tt> specifies the program to use to build the
-shared library from a compiled object file; typically ``${LD}''
-though on some systems it is better to use the C compiler directly
-so system-dependent options and libraries are automatically
-supplied. <tt>DSOOPTS</tt> are options that must be specified to
-<tt>DSOLD</tt> when building the shared library. <tt>LIBCOPTS</tt>
-are options to pass to the C compiler when constructing a
-relocatable object file to include in a shared library; e.g. ``-K
-PIC'' on a Sun system. The <tt>DSO</tt> parameter must also be set
-to a unique label that identifies the target system and compilation
-tools. This label is used to select a target in
-<b>libtiff/</b> to do the actual work in building the
-shared library. Finally, to complete support for the shared library
-added the appropriate rules to <b>libtiff/</b> under the
-target specified in the <tt>configure</tt> script. <a name="PC" id=
+<a name="PC" id="PC"></a>
 <h2>Building the Software under Windows 95/98/NT/2000 with MS
 With Microsoft Visual C++ installed, and properly configured for
@@ -441,7 +228,7 @@ <h2>Building the Software under Windows 95/98/NT/2000 with MS
 can extract the files using Windows normal line termination
 conventions with a command similar to:</p>
-  unzip -aa -a
+  unzip -aa -a
 <p>By default libtiff expects that a pre-built zlib and jpeg
 library are provided by the user. If this is not the case, then you
@@ -453,20 +240,20 @@ <h2>Building the Software under Windows 95/98/NT/2000 with MS
 not be able to open some TIFF files.</p>
 <p>To build using the provided you may use:</p>
-  C:\tiff-3.7.4&gt; nmake /f clean
-  C:\tiff-3.7.4&gt; nmake /f
+  C:\tiff-4.0.0&gt; nmake /f clean
+  C:\tiff-4.0.0&gt; nmake /f
     or (the hard way)
-  C:\tiff-3.7.4&gt; cd port
-  C:\tiff-3.7.4\port&gt; nmake /f clean
-  C:\tiff-3.7.4\port&gt; nmake /f
-  C:\tiff-3.7.4&gt; cd ../libtiff
-  C:\tiff-3.7.4\libtiff&gt; nmake /f clean
-  C:\tiff-3.7.4\libtiff&gt; nmake /f
-  C:\tiff-3.7.4\libtiff&gt; cd ..\tools
-  C:\tiff-3.7.4\tools&gt; nmake /f clean
-  C:\tiff-3.7.4\tools&gt; nmake /f
+  C:\tiff-4.0.0&gt; cd port
+  C:\tiff-4.0.0\port&gt; nmake /f clean
+  C:\tiff-4.0.0\port&gt; nmake /f
+  C:\tiff-4.0.0&gt; cd ../libtiff
+  C:\tiff-4.0.0\libtiff&gt; nmake /f clean
+  C:\tiff-4.0.0\libtiff&gt; nmake /f
+  C:\tiff-4.0.0\libtiff&gt; cd ..\tools
+  C:\tiff-4.0.0\tools&gt; nmake /f clean
+  C:\tiff-4.0.0\tools&gt; nmake /f
 <p>This will build the library file
 <tt>libtiff\libtiff\libtiff.lib</tt>. This can be used in Win32
@@ -479,70 +266,8 @@ <h2>Building the Software under Windows 95/98/NT/2000 with MS
 to include the LIBTIFF\LIBTIFF directory in the include path.</p>
 <p>The <tt>libtiff\tools\</tt> should build .exe's for
 all the standard TIFF tool programs.</p>
-<p><a name="DJGPP" id="DJGPP"></a></p>
-<h2>Building the Software under MS/DOS with the DJGPP v2
-[<i>From the file <b>contrib/dosdjgpp/README</b>.</i>]
-<p>The directory <b>contrib/dosdjgpp</b> contains the files
-necessary to build the library and tools with the DJGPP v2 compiler
-under MSDOS.</p>
-<p>All you have to do is copy the files in the directory into the
-respective directories and run make. If you want, you can use the
-<b>conf.bat</b> script to do that for you, make sure that the file
-is stored with MSDOS text EOL-convention (CR/LF), otherwise the
-<b></b> will not do anything.</p>
-<p>Note that you probably will not be able to build the library
-with the v1.x versions of djgpp, due to two problems. First, the
-top makefile calls a sub-make for each directory and you are likely
-to run out of memory, since each recursive invocation of a djgpp
-v1.x program requires about 130k, to avoid that, you can enter the
-directories manually and call make (well, there are only two dirs).
-The 2nd problem is that djgpp 1.x doesn't call the coff2exe
-(stubify) program when creating an executable. This means that all
-programs compiled are not converted to exe and consequently are not
-available for calling directly. For the tools directory, you can
-just call coff2exe for each program after make finishes, but in the
-libtiff directory, a few programs are created during the make
-process that have to be called for make to continue (e.g.
-mkg3states). Make will probably report an error at each such stage.
-To fix that, either add a coff2exe call before each program is
-called or call coff2exe manually and rerun make (there 2-3 such
-programs). <a name="MacMPW" id="MacMPW"></a></p>
-<h2>Building the Software on a Macintosh with MPW</h2>
-The directory <b>contrib/mac-mpw</b> contains support for compiling
-the library and tools under the MPW Shell on a Macintosh system.
-This support was contributed by Niles Ritter (<a href=
-<p>[<i>From the file <b>contrib/mac-mpw/README</b>.</i>]</p>
-<p>This directory contains all of the utilities and makefile source
-to build the LIBTIFF library and tools from the MPW Shell. The file
-BUILD.mpw in this directory is an executable script which uses all
-of these files to create the MPW makefiles and run them.</p>
-<p>The &lt;file&gt;.make files are not MPW makefiles as such, but
-are when run through the "mactrans" program, which turns the ascii
-"%nn" metacharacters into the standard weird MPW make
-<p>This translation trick is necessary to protect the files when
-they are put into unix tarfiles, which tend to mangle the special
-characters. <a name="MacCW" id="MacCW"></a></p>
-<h2>Building the Software on a Macintosh with CodeWarrior</h2>
-The directory <b>contrib/mac-cw</b> contains support for compiling
-the library and tools with MetroWerks CodeWarrior 6.1 on a
-Macintosh system. This support was contributed by Niles Ritter
-(<a href=
-<p>[<i>From the file <b>contrib/mac-cw/README</b>.</i>] In this
-directory you will find a Makefile.script Applescript file, which
-should be run in order to build the libtiff code using MetroWerks
-CodeWarrior. Refer to the "metrowerks.note" instructions on
-building the library for 68k and PowerPC native code, as well as
-building some of the libtiff tools, which are rather unix-like, but
-at least give an example of how to link everything together.
-<a name="VMS" id="VMS"></a></p>
+<a name="VMS" id="VMS"></a>
 <h2>Building the Software on a VMS System</h2>
 The VMS port was done by Karsten Spang (<a href=
 ""></a>), who also "sort of"
@@ -657,88 +382,9 @@ <h3>Linking your own program to the TIFF library on a VMS
 on another machine, and for some reason don't want to have the
 library on that machine. If you plan to have more than one program
 (including the tools) on the machine, it is recommended that you
-copy the library to the other machine and use method 1. <a name=
-"Acorn" id="Acorn"></a></p>
-<h2>Building the Software on an Acorn RISC OS system</h2>
-The directory <b>contrib/acorn</b> contains support for compiling
-the library under Acorn C/C++ under Acorn's RISC OS 3.10 or above.
-Subsequent pathnames will use the Acorn format: The full-stop or
-period character is a pathname delimeter, and the slash character
-is not interpreted; the reverse position from Unix. Thus
-"libtiff/tif_acorn.c" becomes "libtiff.tif_acorn/c".
-<p>This support was contributed by Peter Greenham. (<a href=
-<h3>Installing LibTIFF:</h3>
-<p>LIBTIFF uses several files which have names longer than the
-normal RISC OS maximum of ten characters. This complicates matters.
-Maybe one day Acorn will address the problem and implement long
-filenames properly. Until then this gets messy, especially as I'm
-trying to do this with obeyfiles and not have to include binaries
-in this distribution.</p>
-<p>First of all, ensure you have Truncate configured on (type
-<tt>*Configure Truncate On</tt>)</p>
-<p>Although it is, of course, preferable to have long filenames,
-LIBTIFF can be installed with short filenames, and it will compile
-and link without problems. However, <i>getting</i> it there is more
-problematic. <b>contrib.acorn.install</b> is an installation
-obeyfile which will create a normal Acorn-style library from the
-source (ie: with c, h and o folders etc.), but needs the
-distribution library to have been unpacked into a location which is
-capable of supporting long filenames, even if only temporarily.</p>
-<p>My recommendation, until Acorn address this problem properly, is
-to use Jason Tribbeck's <a href=
-LongFilenames</a>, or any other working system that gives you long
-filenames, like a nearby NFS server for instance.</p>
-<p>If you are using Longfilenames, even if only temporarily to
-install LIBTIFF, unpack the TAR into a RAMDisc which has been
-longfilenamed (ie: <tt>*addlongfs ram</tt>) and then install from
-there to the hard disk. Unfortunately Longfilenames seems a bit
-unhappy about copying a bunch of long-named files across the same
-filing system, but is happy going between systems. You'll need to
-create a ramdisk of about 2Mb.</p>
-<p>Now you can run the installation script I've supplied (in
-contrib.acorn), which will automate the process of installing
-LIBTIFF as an Acorn-style library. The syntax is as follows:</p>
-<p><tt>install &lt;source_dir&gt; &lt;dest_dir&gt;</tt></p>
-<p>Install will then create &lt;dest_dir&gt; and put the library in
-there. For example, having used LongFilenames on the RAMDisk and
-unpacked the library into there, you can then type:</p>
-<p><tt>Obey RAM::RamDisc0.$.contrib.acorn.install RAM::RamDisc0.$
-<p>It doesn't matter if the destination location can cope with long
-filenames or not. The filenames will be truncated if necessary
-(*Configure Truncate On if you get errors) and all will be
-<h3>Compiling LibTIFF:</h3>
-<p>Once the LibTIFF folder has been created and the files put
-inside, making the library should be just a matter of running
-'<b>SetVars</b>' to set the appropriate system variables, then
-running '<b>Makefile</b>'.</p>
-<p><a href=
-is a comprehensive API for RISC OS machines, written by Jonathan
-Coxhead of Acorn Computers (although OSLib is not an official Acorn
-product). Using the OSLib SWI veneers produces code which is more
-compact and more efficient than code written using _kernel_swi or
-_swi. The Acorn port of LibTIFF can take advantage of this if
-present. Edit the Makefile and go to the Static dependencies
-section. The first entry is:</p>
-# Static dependencies:
-@.o.tif_acorn:   @.c.tif_acorn
-        cc $(ccflags) -o @.o.tif_acorn @.c.tif_acorn 
-<p>Change the cc line to:</p>
-        cc $(ccflags) -DINCLUDE_OSLIB -o @.o.tif_acorn @.c.tif_acorn 
-<p>Remember, however, that OSLib is only <i>recommended</i> for
-efficiency's sake. It is not required. <a name="Other" id=
+copy the library to the other machine and use method 1.</p>
+<a name="Other" id="Other"></a>
 <h2>Building the Software on Other Systems</h2>
 This section contains information that might be useful if you are
 working on a non-UNIX system that is not directly supported. All
@@ -828,8 +474,6 @@ <h2>Table of Contents</h2>
 libtiff/tif_predict.h           private defs for Predictor tag support
 libtiff/uvcode.h                LogL/LogLuv codec-specific definitions
 libtiff/version.h               version st

(Patch may be truncated, please check the link at the top of this post.)