![](+"images/cramps.gif")
Building the Software Distribution Building the Software Distribution+hyla% cd tiff-v3.4beta099 +hyla% ./configure + ...lots of messages... +hyla% make + ...lots of messages... +hyla# make install +
In general, the software is designed such that the following +should be ``make-able'' in each directory:
++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 +
+hyla% cd tiff-v3.4beta099 +hyla% ls +COPYRIGHT VERSION config.sub dist man +Makefile.in config.guess configure html port +README config.site contrib libtiff tools +hyla% ./configure +
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.
++hyla% cd tiff-v3.4beta099 +hyla% mkdir obj obj/mycpu +hyla% cd obj/mycpu +hyla% ../../configure +
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 /usr/local hierarchy. To +change this behaviour the appropriate parameters can be specified +on the command line to configure. Run ./configure --help to +get a list of possible options. Installation related options are +shown below.
++ +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 + ++ +
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.
+--enable-rpath Enable runtime linker +paths (-R libtool option)
+Add library directories (see other options below) to the TIFF +library run-time linker path.
++ +wullbrandt% mkdir tiff +wullbrandt% cd tiff +wullbrandt% ln -s /hosts/oxford/usr/people/sam/tiff src + +
+ +wullbrandt% src/configure +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! + +
+ +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. + +
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 ENVOPTS parameter.
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.
++ +Using /usr/ucb/make to configure the software. + +
Creating port.h. The port.h 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, #defines to enable or disable +system-specific functionality, and other odds and ends.
++ +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. + +
Selecting emulated library functions. 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 port directory to use +instead. Building the TIFF software on unsupported systems may +require adding to the code to the port directory.
++ +Checking system libraries for functionality to emulate. +Done checking system libraries. + +
+ +Checking for Dynamic Shared Object (DSO) support. +Done checking for DSO support. + +
Selecting utility programs. configure locates various +system utility programs that are used during installation of the +software.
++ +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. + +
Selecting default configuration parameters. 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.
++ +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]? + +
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.
++ +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. + +
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 DSO +parameter is handled and add a new case for the target system that +sets the DSOSUF, DSOLD, DSOOPTS, and +LIBCOPTS options as appropriate for the system. +DSOSUF specifies the filename suffix used for the shared +library (e.g. ``.so'' for Dynamic Shared Objects on most SVR4-based +systems). DSOLD 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. DSOOPTS are options that must be specified to +DSOLD when building the shared library. LIBCOPTS +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 DSO 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 +libtiff/Makefile.in to do the actual work in building the +shared library. Finally, to complete support for the shared library +added the appropriate rules to libtiff/Makefile.in under the +target specified in the configure script.
+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 Info-Zip package, you +can extract the files using Windows normal line termination +conventions with a command similar to:
++ unzip -aa -a tiff-3.7.4.zip ++
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.
+To build using the provided makefile.vc you may use:
++ 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 ++
This will build the library file +libtiff\libtiff\libtiff.lib. This can be used in Win32 +programs. You may want to adjust the build options before start +compiling. All parameters contained in the nmake.opt +file.This is a plain text file you can open with your favorite text +editor.
+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.
+The libtiff\tools\makefile.vc should build .exe's for +all the standard TIFF tool programs.
+ +The directory contrib/dosdjgpp contains the files +necessary to build the library and tools with the DJGPP v2 compiler +under MSDOS.
+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 +conf.bat script to do that for you, make sure that the file +is stored with MSDOS text EOL-convention (CR/LF), otherwise the +command.com will not do anything.
+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).
+[From the file contrib/mac-mpw/README.]
+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.
+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.
+This translation trick is necessary to protect the files when +they are put into unix tarfiles, which tend to mangle the special +characters.
+[From the file contrib/mac-cw/README.] 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. +
++$ SET DEFAULT DISK:[TIFF.CONTRIB.VMS] +$ RENAME [.LIBTIFF]*.* [-.-.LIBTIFF] +$ RENAME [.TOOLS]*.* [-.-.TOOLS] +
+$ SET DEFAULT DISK:[TIFF.LIBTIFF] +$ @MAKEVMS +
+$ SET DEFAULT DISK:[TIFF.TOOLS] +$ @MAKEVMS +
+$ 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 +
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*.
+The command procedures (MAKEVMS.COM) for building the +library and tools, is believed to choose the correct options for +the VAX and AXP cases automatically.
+On the AXP, IEEE floating point is used by default. If you want +VAX floating point, remove the /FLOAT=IEEE_FLOAT +qualifier, and change HAVE_IEEEFP=1 to +HAVE_IEEEFP=0 in the MAKEVMS.COM files in both +the libtiff and tools directories.
++ $ CC/INCLUDE=DISK:[TIFF.LIBTIFF] ++This ensures that the header file is found. On the AXP, also add +/FLOAT=IEEE_FLOAT (if used when building the library). +
+$ LINK MY_PROGRAM,DISK:[TIFF.LIBTIFF]TIFF/OPTIONS,SYS$INPUT:/OPTIONS + SYS$SHARE:VAXCRTL/SHAREABLE +
+$ LINK MY_PROGRAM, - + DISK:[TIFF.LIBTIFF]TIFF/LIBRARY/INCLUDE=(TIF_FAX3SM,TIF_CODEC), - + SYS$INPUT:/OPTIONS + SYS$SHARE:VAXCRTL/SHAREABLE +
+$ LINK MY_PROGRAM,DISK:[TIFF.LIBTIFF]TIFF/OPTIONS +
+$ LINK MY_PROGRAM,DISK:[TIFF.LIBTIFF]TIFF/LIBRARY +
Method 2 gives somewhat longer link time and larger +.EXE files, but does not require TIFFSHR 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.
+This support was contributed by Peter Greenham. (peter@enlarion.demon.co.uk).
+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.
+First of all, ensure you have Truncate configured on (type +*Configure Truncate On)
+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, getting it there is more +problematic. contrib.acorn.install 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.
+My recommendation, until Acorn address this problem properly, is +to use Jason Tribbeck's +LongFilenames, or any other working system that gives you long +filenames, like a nearby NFS server for instance.
+If you are using Longfilenames, even if only temporarily to +install LIBTIFF, unpack the TAR into a RAMDisc which has been +longfilenamed (ie: *addlongfs ram) 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.
+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:
+install <source_dir> <dest_dir>
+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:
+Obey RAM::RamDisc0.$.contrib.acorn.install RAM::RamDisc0.$ +ADFS::4.$.LIBTIFF
+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.
+Once the LibTIFF folder has been created and the files put +inside, making the library should be just a matter of running +'SetVars' to set the appropriate system variables, then +running 'Makefile'.
+OSLib
+OSLib +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:
++# Static dependencies: +@.o.tif_acorn: @.c.tif_acorn + cc $(ccflags) -o @.o.tif_acorn @.c.tif_acorn ++
Change the cc line to:
++ cc $(ccflags) -DINCLUDE_OSLIB -o @.o.tif_acorn @.c.tif_acorn ++
Remember, however, that OSLib is only recommended for +efficiency's sake. It is not required.
+The library requires two files that are generated +on-the-fly. The file tif_fax3sm.c has the state +tables for the Group 3 and Group 4 decoders. This file is generated +by the mkg3states program on a UNIX system; for +example,
++ +cd libtiff +cc -o mkg3states mkg3states.c +rm -f tif_fax3sm.c +./mkg3states -c const tif_fax3sm.c + +
The second file required to build the library, version.h, +contains the version information returned by the +TIFFGetVersion routine. This file is built on most systems +using the mkversion program and the contents of the +VERSION and tiff.alpha files; for example,
++cd libtiff +cc -o mkversion mkversion.c +rm -f version.h +./mkversion -v ../VERSION -a ../dist/tiff.alpha version.h +
Otherwise, when building the library on a non-UNIX system be +sure to consult the files tiffcomp.h and tiffconf.h. +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.
+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 documentation.
+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 port directory is provided to emulate routines +that may be missing on some systems. On UNIX systems the +configure script automatically figures out which routines +are not present on a system and enables the use of the equivalent +emulation routines from the port directory. It may be +necessary to manually do this work on a non-UNIX system.
+Assuming you have working versions of tiffgt and +tiffsv, you can just use them to view any of the sample +images available for testing (see the section +on obtaining the test images). Otherwise, you can do a cursory +check of the library with the tiffcp and tiffcmp +programs. For example,
++tiffcp -lzw cramps.tif x.tif +tiffcmp cramps.tif x.tif +
(tiffcmp should be silent if the files compare +correctly).
++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. ++