summaryrefslogtreecommitdiffstats
path: root/src/3rdparty/libtiff/html/build.html
diff options
context:
space:
mode:
authorLars Knoll <lars.knoll@nokia.com>2009-03-23 09:34:13 (GMT)
committerSimon Hausmann <simon.hausmann@nokia.com>2009-03-23 09:34:13 (GMT)
commit67ad0519fd165acee4a4d2a94fa502e9e4847bd0 (patch)
tree1dbf50b3dff8d5ca7e9344733968c72704eb15ff /src/3rdparty/libtiff/html/build.html
downloadQt-67ad0519fd165acee4a4d2a94fa502e9e4847bd0.zip
Qt-67ad0519fd165acee4a4d2a94fa502e9e4847bd0.tar.gz
Qt-67ad0519fd165acee4a4d2a94fa502e9e4847bd0.tar.bz2
Long live Qt!
Diffstat (limited to 'src/3rdparty/libtiff/html/build.html')
-rw-r--r--src/3rdparty/libtiff/html/build.html880
1 files changed, 880 insertions, 0 deletions
diff --git a/src/3rdparty/libtiff/html/build.html b/src/3rdparty/libtiff/html/build.html
new file mode 100644
index 0000000..e0b2157
--- /dev/null
+++ b/src/3rdparty/libtiff/html/build.html
@@ -0,0 +1,880 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+<meta name="generator" content=
+"HTML Tidy for Solaris (vers 12 April 2005), see www.w3.org">
+<title>Building the TIFF Software Distribution</title>
+</head>
+<body bgcolor="white">
+<h1><font face="Arial, Helvetica, Sans"><img src=
+"images/cramps.gif" width="159" height="203" align="left" border=
+"1" hspace="6"> Building the Software Distribution</font></h1>
+<ul>
+<li><a href="#UNIX">Building on a UNIX system</a>.</li>
+<li><a href="#MacMPW">Building on a Macintosh system with
+MPW</a>.</li>
+<li><a href="#MacCW">Building on a Macintosh system with
+CodeWarrior</a>.</li>
+<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
+compiler</a>.</li>
+<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
+Systems</a></li>
+</ul>
+<br clear="left">
+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>
+<hr>
+<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
+source directory. This script probes the target system for
+necessary tools and functions and constructs a build environment in
+which the software may be compiled. Once configuration is done, you
+simply run <tt>make</tt> (or <tt>gmake</tt>) to build the software
+and then <tt>make install</tt> to do the installation; for example:
+<div style="margin-left: 2em">
+<pre>
+hyla% <b>cd tiff-v3.4beta099</b>
+hyla% <b>./configure</b>
+ <i>...lots of messages...</i>
+hyla% <b>make</b>
+ <i>...lots of messages...</i>
+hyla# <b>make install</b>
+</pre></div>
+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
+<b>./configure</b>.
+<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">
+<pre>
+make [all] build stuff
+make install build&amp;install stuff
+make clean remove .o files, executables and cruft
+make distclean remove everything, that can be recreated
+</pre></div>
+Note that after running "<tt>make distclean</tt>" the
+<tt>configure</tt> script must be run again to create the Makefiles
+and other make-related files. <a name="BuildTrees" id=
+"BuildTrees"></a>
+<hr width="65%" align="right">
+<h3>Build Trees</h3>
+There are two schemes for configuring and building the software. If
+you intend to build the software for only one target system, you
+can configure the software so that it is built in the same
+directories as the source code.
+<div style="margin-left: 2em">
+<pre>
+hyla% <b>cd tiff-v3.4beta099</b>
+hyla% <b>ls</b>
+COPYRIGHT VERSION config.sub dist man
+Makefile.in config.guess configure html port
+README config.site contrib libtiff tools
+hyla% <b>./configure</b>
+</pre></div>
+<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>
+<div style="margin-left: 2em">
+<pre>
+hyla% <b>cd tiff-v3.4beta099</b>
+hyla% <b>mkdir obj obj/mycpu</b>
+hyla% <b>cd obj/mycpu</b>
+hyla% <b>../../configure</b>
+</pre></div>
+This second scheme is useful for:
+<ul>
+<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>
+</ul>
+<a name="ConfigOptions" id="ConfigOptions"></a>
+<hr width="65%" align="right">
+<h3>Configuration Options</h3>
+The configuration process is critical to the proper compilation,
+installation, and operation of the software. The configure script
+runs a series of tests to decide whether or not the target system
+supports required functionality and, if it does not, whether it can
+emulate or workaround the missing functions. This procedure is
+fairly complicated and, due to the nonstandard nature of most UNIX
+systems, prone to error. The first time that you configure the
+software for use you should check the output from the configure
+script and look for anything that does not make sense for your
+system.
+<p>A second function of the configure script is to set the default
+configuration parameters for the software. Of particular note are
+the directories where the software is to be installed. By default
+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>
+<pre>
+<tt>
+Installation directories:
+ --prefix=PREFIX install architecture-independent files in PREFIX
+ [/usr/local]
+ --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
+ [PREFIX]
+
+By default, `make install' will install all the files in
+`/usr/local/bin', `/usr/local/lib' etc. You can specify
+an installation prefix other than `/usr/local' using `--prefix',
+for instance `--prefix=$HOME'.
+
+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]
+
+Program names:
+ --program-prefix=PREFIX prepend PREFIX to installed program names
+ --program-suffix=SUFFIX append SUFFIX to installed program names
+ --program-transform-name=PROGRAM run sed PROGRAM on installed program names
+</tt>
+</pre>
+<a name="Packages" id="Packages"></a>
+<hr width="65%" align="right">
+<h3>Configuring Optional Packages/Support</h3>
+The TIFF software comes with several packages that are installed
+only as needed, or only if specifically configured at the time the
+configure script is run. Packages can be configured via the
+<b>configure</b> script commandline parameters.
+<dl>
+<dt><i>Static/Shared Objects Support</i></dt>
+<dd><tt>--enable-shared[=PKGS]&nbsp;&nbsp;&nbsp;&nbsp;build shared
+libraries [default=yes]<br>
+--enable-static[=PKGS]&nbsp;&nbsp;&nbsp;&nbsp;build static
+libraries [default=yes]</tt>
+<p>These options control whether or not to configure the software
+to build a shared and static binaries for the TIFF library. Use of
+shared libraries can significantly reduce the disk space needed for
+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>
+<p>Add library directories (see other options below) to the TIFF
+library run-time linker path.</p>
+</dd>
+<dt><i>JPEG Support</i></dt>
+<dd><tt>--disable-jpeg&nbsp;&nbsp;&nbsp;&nbsp;disable IJG JPEG
+library usage (required for JPEG compression, enabled by default)
+--with-jpeg-include-dir=DIR&nbsp;&nbsp;&nbsp;&nbsp;location of IJG
+JPEG library headers
+--with-jpeg-lib-dir=DIR&nbsp;&nbsp;&nbsp;&nbsp;location of IJG JPEG
+library binary)</tt></dd>
+<dd>The <tt>JPEG</tt> package enables support for the handling of
+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=
+"ftp://ftp.uu.net/graphics/jpeg/">ftp.uu.net:/graphics/jpeg/</a>.
+<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>
+<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=
+"ftp://ftp.uu.net/pub/archiving/zip/zlib/">ftp.uu.net:/pub/archiving/zip/zlib/</a>
+(or try <a href=
+"ftp://quest.jpl.nasa.gov/beta/zlib/">quest.jpl.nasa.gov:/beta/zlib/</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 configured.</dd>
+</dl>
+<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">
+<pre>
+<tt>
+wullbrandt% <b>mkdir tiff</b>
+wullbrandt% <b>cd tiff</b>
+wullbrandt% <b>ln -s /hosts/oxford/usr/people/sam/tiff src</b>
+</tt>
+</pre></div>
+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">
+<pre>
+<tt>
+wullbrandt% <b>src/configure</b>
+Configuring TIFF Software v3.4beta015.
+
+Reading site-wide parameters from ../tiff-v3.4beta015/config.site.
+Reading local parameters from config.local.
+Gosh, aren't you lucky to have a i386-unknown-bsdi1.1 system!
+</tt>
+</pre></div>
+Note that configure announces the distribution version and the
+deduced target configuration (<tt>i386-unknown-bsdi1.1</tt> here).
+<div style="margin-left: 2em">
+<pre>
+<tt>
+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.
+</tt>
+</pre></div>
+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">
+<pre>
+<tt>
+Using /usr/ucb/make to configure the software.
+</tt>
+</pre></div>
+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">
+<pre>
+<tt>
+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.
+</tt>
+</pre></div>
+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">
+<pre>
+<tt>
+Checking system libraries for functionality to emulate.
+Done checking system libraries.
+</tt>
+</pre></div>
+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">
+<pre>
+<tt>
+Checking for Dynamic Shared Object (DSO) support.
+Done checking for DSO support.
+</tt>
+</pre></div>
+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
+software.</p>
+<div style="margin-left: 2em">
+<pre>
+<tt>
+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.
+</tt>
+</pre></div>
+<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">
+<pre>
+<tt>
+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]?
+</tt>
+</pre></div>
+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">
+<pre>
+<tt>
+Creating Makefile from ../tiff-v3.4beta015/Makefile.in
+Creating libtiff/Makefile from ../tiff-v3.4beta015/libtiff/Makefile.in
+Creating man/Makefile from ../tiff-v3.4beta015/man/Makefile.in
+Creating tools/Makefile from ../tiff-v3.4beta015/tools/Makefile.in
+Creating port/install.sh from ../tiff-v3.4beta015/port/install.sh.in
+Done.
+</tt>
+</pre></div>
+<a name="DSOSupport" id="DSOSupport"></a>
+<hr>
+<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/Makefile.in</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
+system.
+<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/Makefile.in</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/Makefile.in</b> under the
+target specified in the <tt>configure</tt> script. <a name="PC" id=
+"PC"></a></p>
+<hr>
+<h2>Building the Software under Windows 95/98/NT/2000 with MS
+VC++</h2>
+With Microsoft Visual C++ installed, and properly configured for
+commandline use (you will likely need to source VCVARS32.BAT in
+AUTOEXEC.bAT or somewhere similar) you should be able to use the
+provided <tt>makefile.vc</tt>.
+<p>The source package is delivered using Unix line termination
+conventions, which work with MSVC but do not work with Windows
+'notepad'. If you use unzip from the <a href=
+"http://www.info-zip.org/pub/infozip/">Info-Zip</a> package, you
+can extract the files using Windows normal line termination
+conventions with a command similar to:</p>
+<pre>
+ unzip -aa -a tiff-3.7.4.zip
+</pre>
+<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
+may edit libtiff\tiffconf.h using a text editor (e.g. notepad) and
+comment out the entries for JPEG_SUPPORT, PIXARLOG_SUPPORT, and
+ZIP_SUPPORT. Ignore the comment at the top of the file which says
+that it has no influence on the build, because the statement is not
+true for Windows. However, by taking this approach, libtiff will
+not be able to open some TIFF files.</p>
+<p>To build using the provided makefile.vc you may use:</p>
+<pre>
+ C:\tiff-3.7.4&gt; nmake /f makefile.vc clean
+ C:\tiff-3.7.4&gt; nmake /f makefile.vc
+
+ or (the hard way)
+
+ C:\tiff-3.7.4&gt; cd port
+ C:\tiff-3.7.4\port&gt; nmake /f makefile.vc clean
+ C:\tiff-3.7.4\port&gt; nmake /f makefile.vc
+ C:\tiff-3.7.4&gt; cd ../libtiff
+ C:\tiff-3.7.4\libtiff&gt; nmake /f makefile.vc clean
+ C:\tiff-3.7.4\libtiff&gt; nmake /f makefile.vc
+ C:\tiff-3.7.4\libtiff&gt; cd ..\tools
+ C:\tiff-3.7.4\tools&gt; nmake /f makefile.vc clean
+ C:\tiff-3.7.4\tools&gt; nmake /f makefile.vc
+</pre>
+<p>This will build the library file
+<tt>libtiff\libtiff\libtiff.lib</tt>. This can be used in Win32
+programs. You may want to adjust the build options before start
+compiling. All parameters contained in the <tt>nmake.opt</tt>
+file.This is a plain text file you can open with your favorite text
+editor.</p>
+<p>The makefile also builds a DLL (libtiff.dll) with an associated
+import library (libtiff_i.lib). Any builds using libtiff will need
+to include the LIBTIFF\LIBTIFF directory in the include path.</p>
+<p>The <tt>libtiff\tools\makefile.vc</tt> should build .exe's for
+all the standard TIFF tool programs.</p>
+<p><a name="DJGPP" id="DJGPP"></a></p>
+<hr>
+<h2>Building the Software under MS/DOS with the DJGPP v2
+compiler</h2>
+[<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>command.com</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>
+<hr>
+<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=
+"mailto:ndr@tazboy.jpl.nasa.gov">ndr@tazboy.jpl.nasa.gov</a>).
+<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
+characters.</p>
+<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>
+<hr>
+<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=
+"mailto:ndr@tazboy.jpl.nasa.gov">ndr@tazboy.jpl.nasa.gov</a>).
+<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>
+<hr>
+<h2>Building the Software on a VMS System</h2>
+The VMS port was done by Karsten Spang (<a href=
+"mailto:krs@kampsax.dk">krs@kampsax.dk</a>), who also "sort of"
+maintains it. The VMS specific files are not in the main
+directories. Instead they are placed under
+<tt>[.CONTRIB.VMS...]</tt> in the distribution tree. Installation:
+It is assumed that you have unpacked the tar file into a VMS
+directory tree, in this text called DISK:[TIFF].
+<ol>
+<li>Move the VMS specific files to their proper directories.
+<pre>
+$ SET DEFAULT DISK:[TIFF.CONTRIB.VMS]
+$ RENAME [.LIBTIFF]*.* [-.-.LIBTIFF]
+$ RENAME [.TOOLS]*.* [-.-.TOOLS]
+</pre></li>
+<li>Compile the library.
+<pre>
+$ SET DEFAULT DISK:[TIFF.LIBTIFF]
+$ @MAKEVMS
+</pre></li>
+<li>Compile the tools.
+<pre>
+$ SET DEFAULT DISK:[TIFF.TOOLS]
+$ @MAKEVMS
+</pre></li>
+<li>Define the programs.
+<pre>
+$ DEFINE TIFFSHR DISK:[TIFF.LIBTIFF]TIFFSHR
+$ FAX2PS :==$DISK:[TIFF.TOOLS]FAX2PS
+$ FAX2TIFF :==$DISK:[TIFF.TOOLS]FAX2TIFF
+$ GIF2TIFF :==$DISK:[TIFF.TOOLS]GIF2TIFF
+$ PAL2RGB :==$DISK:[TIFF.TOOLS]PAL2RGB
+$ PPM2TIFF :==$DISK:[TIFF.TOOLS]PPM2TIFF
+$ RAS2TIFF :==$DISK:[TIFF.TOOLS]RAS2TIFF
+$ RGB2YCBCR :==$DISK:[TIFF.TOOLS]RGB2YCBCR
+$ THUMBNAIL :==$DISK:[TIFF.TOOLS]THUMBNAIL
+$ TIFF2BW :==$DISK:[TIFF.TOOLS]TIFF2BW
+$ TIFF2PS :==$DISK:[TIFF.TOOLS]TIFF2PS
+$ TIFFCMP :==$DISK:[TIFF.TOOLS]TIFFCMP
+$ TIFFCP :==$DISK:[TIFF.TOOLS]TIFFCP
+$ TIFFDITHER:==$DISK:[TIFF.TOOLS]TIFFDITHER
+$ TIFFDUMP :==$DISK:[TIFF.TOOLS]TIFFDUMP
+$ TIFFINFO :==$DISK:[TIFF.TOOLS]TIFFINFO
+$ TIFFMEDIAN:==$DISK:[TIFF.TOOLS]TIFFMEDIAN
+$ TIFFSPLIT :==$DISK:[TIFF.TOOLS]TIFFSPLIT
+$ YCBCR :==$DISK:[TIFF.TOOLS]YCBCR
+</pre></li>
+</ol>
+You will want to add these lines to your <tt>LOGIN.COM</tt> file,
+after changing the name of the directory that you have used on your
+machine.
+<p>This release has been tested on OpenVMS/VAX 5.5-2, using VAX C
+3.2. A previous release was tested under OpenVMS/AXP ?.? using DEC
+C ?.?, it is believed that this release as well works on AXP. The
+code contains some GNU C specific things. This does *not* imply,
+however, that the VAX/GCC configuration has been tested, *it has
+not*.</p>
+<p>The command procedures (<tt>MAKEVMS.COM</tt>) for building the
+library and tools, is believed to choose the correct options for
+the VAX and AXP cases automatically.</p>
+<p>On the AXP, IEEE floating point is used by default. If you want
+VAX floating point, remove the <tt>/FLOAT=IEEE_FLOAT</tt>
+qualifier, and change <tt>HAVE_IEEEFP=1</tt> to
+<tt>HAVE_IEEEFP=0</tt> in the <tt>MAKEVMS.COM</tt> files in both
+the <b>libtiff</b> and <b>tools</b> directories.</p>
+<h3>Compiling your own program on a VMS system:</h3>
+When compiling a source file in which you <tt>"#include
+&lt;tiffio.h&gt;"</tt>, use the following command
+<pre>
+ $ CC/INCLUDE=DISK:[TIFF.LIBTIFF]
+</pre>
+This ensures that the header file is found. On the AXP, also add
+<tt>/FLOAT=IEEE_FLOAT</tt> (if used when building the library).
+<h3>Linking your own program to the TIFF library on a VMS
+system:</h3>
+You can link to the library in two ways: Either using the shareable
+library, or using the object library. On the VAX these
+possibilities are:
+<ol>
+<li>Using the shareable TIFF library.
+<pre>
+$ LINK MY_PROGRAM,DISK:[TIFF.LIBTIFF]TIFF/OPTIONS,SYS$INPUT:/OPTIONS
+ SYS$SHARE:VAXCRTL/SHAREABLE
+</pre></li>
+<li>Using the TIFF object library.
+<pre>
+$ LINK MY_PROGRAM, -
+ DISK:[TIFF.LIBTIFF]TIFF/LIBRARY/INCLUDE=(TIF_FAX3SM,TIF_CODEC), -
+ SYS$INPUT:/OPTIONS
+ SYS$SHARE:VAXCRTL/SHAREABLE
+</pre></li>
+</ol>
+On AXP (and possibly also using DEC C on VAX) the corresponding
+commands are
+<ol>
+<li>Using the shareable TIFF library.
+<pre>
+$ LINK MY_PROGRAM,DISK:[TIFF.LIBTIFF]TIFF/OPTIONS
+</pre></li>
+<li>Using the TIFF object library.
+<pre>
+$ LINK MY_PROGRAM,DISK:[TIFF.LIBTIFF]TIFF/LIBRARY
+</pre></li>
+</ol>
+Method 1 uses the shortest link time and smallest <tt>.EXE</tt>
+files, but it requires that <tt>TIFFSHR</tt> is defined as above at
+link time and <strong>at run time</strong>. Using the compilation
+procedure above, the tools are linked in this way.
+<p>Method 2 gives somewhat longer link time and larger
+<tt>.EXE</tt> files, but does not require <tt>TIFFSHR</tt> to be
+defined. This method is recommended if you want to run your program
+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>
+<hr>
+<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=
+"mailto:peter@enlarion.demon.co.uk">peter@enlarion.demon.co.uk</a>).</p>
+<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=
+"ftp://ftp.demon.co.uk/pub/mirrors/hensa/micros/arch/riscos/c/c020/longfiles.arc">
+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.$
+ADFS::4.$.LIBTIFF</tt></p>
+<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
+well.</p>
+<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><b>OSLib</b></p>
+<p><a href=
+"ftp://ftp.acorn.co.uk/pub/riscos/releases/oslib/oslib.arc">OSLib</a>
+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>
+<pre>
+# Static dependencies:
+@.o.tif_acorn: @.c.tif_acorn
+ cc $(ccflags) -o @.o.tif_acorn @.c.tif_acorn
+</pre>
+<p>Change the cc line to:</p>
+<pre>
+ cc $(ccflags) -DINCLUDE_OSLIB -o @.o.tif_acorn @.c.tif_acorn
+</pre>
+<p>Remember, however, that OSLib is only <i>recommended</i> for
+efficiency's sake. It is not required. <a name="Other" id=
+"Other"></a></p>
+<hr>
+<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
+library-related files described below are located in the
+<b>libtiff</b> directory.
+<p>The library requires two files that are generated
+<i>on-the-fly</i>. The file <b>tif_fax3sm.c</b> has the state
+tables for the Group 3 and Group 4 decoders. This file is generated
+by the <tt>mkg3states</tt> program on a UNIX system; for
+example,</p>
+<div style="margin-left: 2em">
+<pre>
+<tt>
+cd libtiff
+cc -o mkg3states mkg3states.c
+rm -f tif_fax3sm.c
+./mkg3states -c const tif_fax3sm.c
+</tt>
+</pre></div>
+The <tt>-c</tt> option can be used to control whether or not the
+resutling tables are generated with a <tt>const</tt> declaration.
+The <tt>-s</tt> option can be used to specify a C storage class for
+the table declarations. The <tt>-b</tt> option can be used to force
+data values to be explicitly bracketed with ``{}'' (apparently
+needed for some MS-Windows compilers); otherwise the structures are
+emitted in as compact a format as possible. Consult the source code
+for this program if you have questions.
+<p>The second file required to build the library, <b>version.h</b>,
+contains the version information returned by the
+<tt>TIFFGetVersion</tt> routine. This file is built on most systems
+using the <tt>mkversion</tt> program and the contents of the
+<tt>VERSION</tt> and <tt>tiff.alpha</tt> files; for example,</p>
+<div style="margin-left: 2em">
+<pre>
+cd libtiff
+cc -o mkversion mkversion.c
+rm -f version.h
+./mkversion -v ../VERSION -a ../dist/tiff.alpha version.h
+</pre></div>
+<p>Otherwise, when building the library on a non-UNIX system be
+sure to consult the files <b>tiffcomp.h</b> and <b>tiffconf.h</b>.
+The former contains system compatibility definitions while the
+latter is provided so that the software configuration can be
+controlled on systems that do not support the make facility for
+building the software.</p>
+<p>Systems without a 32-bit compiler may not be able to handle some
+of the codecs in the library; especially the Group 3 and 4 decoder.
+If you encounter problems try disabling support for a particular
+codec; consult the <a href=
+"internals.html#Config">documentation</a>.</p>
+<p>Programs in the tools directory are written to assume an ANSI C
+compilation environment. There may be a few POSIX'isms as well. The
+code in the <b>port</b> directory is provided to emulate routines
+that may be missing on some systems. On UNIX systems the
+<tt>configure</tt> script automatically figures out which routines
+are not present on a system and enables the use of the equivalent
+emulation routines from the <b>port</b> directory. It may be
+necessary to manually do this work on a non-UNIX system. <a name=
+"Testing" id="Testing"></a></p>
+<hr>
+<h2>Checking out the Software</h2>
+<p>Assuming you have working versions of <tt>tiffgt</tt> and
+<tt>tiffsv</tt>, you can just use them to view any of the sample
+images available for testing (see the <a href="images.html">section
+on obtaining the test images</a>). Otherwise, you can do a cursory
+check of the library with the <tt>tiffcp</tt> and <tt>tiffcmp</tt>
+programs. For example,</p>
+<div style="margin-left: 2em">
+<pre>
+tiffcp -lzw cramps.tif x.tif
+tiffcmp cramps.tif x.tif
+</pre></div>
+<p>(<tt>tiffcmp</tt> should be silent if the files compare
+correctly). <a name="TOC" id="TOC"></a></p>
+<hr>
+<h2>Table of Contents</h2>
+The following files makup the core library:
+<pre>
+libtiff/tiff.h TIFF spec definitions
+libtiff/tiffcomp.h non-UNIX OS-compatibility definitions
+libtiff/tiffconf.h non-UNIX configuration definitions
+libtiff/tiffio.h public TIFF library definitions
+libtiff/tiffiop.h private TIFF library definitions
+libtiff/t4.h CCITT Group 3/4 code tables+definitions
+libtiff/tif_dir.h private defs for TIFF directory handling
+libtiff/tif_fax3.h CCITT Group 3/4-related definitions
+libtiff/tif_predict.h private defs for Predictor tag support
+libtiff/uvcode.h LogL/LogLuv codec-specific definitions
+libtiff/version.h version string (generated by Makefile)
+
+libtiff/tif_acorn.c Acorn-related OS support
+libtiff/tif_apple.c Apple-related OS support
+libtiff/tif_atari.c Atari-related OS support
+libtiff/tif_aux.c auxilary directory-related functions
+libtiff/tif_close.c close an open TIFF file
+libtiff/tif_codec.c configuration table of builtin codecs
+libtiff/tif_compress.c compression scheme support
+libtiff/tif_dir.c directory tag interface code
+libtiff/tif_dirinfo.c directory known tag support code
+libtiff/tif_dirread.c directory reading code
+libtiff/tif_dirwrite.c directory writing code
+libtiff/tif_dumpmode.c "no" compression codec
+libtiff/tif_error.c library error handler
+libtiff/tif_fax3.c CCITT Group 3 and 4 codec
+libtiff/tif_fax3sm.c G3/G4 state tables (generated by mkg3states)
+libtiff/tif_flush.c i/o and directory state flushing
+libtiff/tif_getimage.c TIFFRGBAImage support
+libtiff/tif_jpeg.c JPEG codec (interface to the IJG distribution)
+libtiff/tif_luv.c SGI LogL/LogLuv codec
+libtiff/tif_lzw.c LZW codec
+libtiff/tif_msdos.c MSDOS-related OS support
+libtiff/tif_next.c NeXT 2-bit scheme codec (decoding only)
+libtiff/tif_open.c open and simply query code
+libtiff/tif_packbits.c Packbits codec
+libtiff/tif_pixarlog.c Pixar codec
+libtiff/tif_predict.c Predictor tag support
+libtiff/tif_print.c directory printing support
+libtiff/tif_read.c image data reading support
+libtiff/tif_strip.c some strip-related code
+libtiff/tif_swab.c byte and bit swapping support
+libtiff/tif_thunder.c Thunderscan codec (decoding only)
+libtiff/tif_tile.c some tile-related code
+libtiff/tif_unix.c UNIX-related OS support
+libtiff/tif_version.c library version support
+libtiff/tif_vms.c VMS-related OS support
+libtiff/tif_warning.c library warning handler
+libtiff/tif_win3.c Windows-3.1-related OS support
+libtiff/tif_win32.c Win32 (95/98/NT) related OS support
+libtiff/tif_write.c image data writing support
+libtiff/tif_zip.c Deflate codec
+
+libtiff/mkg3states.c program to generate G3/G4 decoder state tables
+libtiff/mkspans.c program to generate black-white span tables
+libtiff/mkversion.c program to generate libtiff/version.h.
+</pre>
+<hr>
+Last updated: $Date: 2005/12/24 22:25:05 $
+</body>
+</html>