| Current Path : /compat/linux/proc/self/root/usr/local/share/doc/tiff/ |
FreeBSD hs32.drive.ne.jp 9.1-RELEASE FreeBSD 9.1-RELEASE #1: Wed Jan 14 12:18:08 JST 2015 root@hs32.drive.ne.jp:/sys/amd64/compile/hs32 amd64 |
| Current File : //compat/linux/proc/self/root/usr/local/share/doc/tiff/build.html |
<!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&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] build shared
libraries [default=yes]<br>
--enable-static[=PKGS] 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 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 disable IJG JPEG
library usage (required for JPEG compression, enabled by default)
--with-jpeg-include-dir=DIR location of IJG
JPEG library headers
--with-jpeg-lib-dir=DIR 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 <fcntl.h>
... 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> nmake /f makefile.vc clean
C:\tiff-3.7.4> nmake /f makefile.vc
or (the hard way)
C:\tiff-3.7.4> cd port
C:\tiff-3.7.4\port> nmake /f makefile.vc clean
C:\tiff-3.7.4\port> nmake /f makefile.vc
C:\tiff-3.7.4> cd ../libtiff
C:\tiff-3.7.4\libtiff> nmake /f makefile.vc clean
C:\tiff-3.7.4\libtiff> nmake /f makefile.vc
C:\tiff-3.7.4\libtiff> cd ..\tools
C:\tiff-3.7.4\tools> nmake /f makefile.vc clean
C:\tiff-3.7.4\tools> 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 <file>.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
<tiffio.h>"</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 <source_dir> <dest_dir></tt></p>
<p>Install will then create <dest_dir> 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>