551 lines
27 KiB
Plaintext
551 lines
27 KiB
Plaintext
SETUP instructions for the Independent JPEG Group's JPEG software
|
|
=================================================================
|
|
|
|
This file explains how to configure and compile the JPEG software. We have
|
|
tried to make this software extremely portable and flexible, so that it can be
|
|
adapted to almost any environment. The downside of this decision is that the
|
|
installation process is not very automatic; you will need at least a little
|
|
familiarity with C programming and program build procedures for your system.
|
|
|
|
This file contains general instructions, then sections of specific hints for
|
|
certain systems. You may save yourself considerable time if you scan the
|
|
whole file before starting to do anything.
|
|
|
|
Before installing the software you must unpack the distributed source code.
|
|
Since you are reading this file, you have probably already succeeded in this
|
|
task. However, there is one potential trap if you are on a non-Unix system:
|
|
you may need to convert these files to the local standard text file format
|
|
(for example, if you are on MS-DOS you probably have to convert LF end-of-line
|
|
to CR/LF). If so, apply the conversion to all the files EXCEPT those whose
|
|
names begin with "test". The test files contain binary data; if you change
|
|
them in any way then the self-test will give bad results.
|
|
|
|
|
|
STEP 1: PREPARE A MAKEFILE
|
|
==========================
|
|
|
|
First, select a makefile and copy it to "Makefile" (or whatever your version
|
|
of make uses as the default makefile name; for example, "makefile.mak" for
|
|
old versions of Borland C). We include several standard makefiles in the
|
|
distribution:
|
|
|
|
makefile.ansi: for Unix systems with ANSI-compatible C compilers.
|
|
makefile.unix: for Unix systems with non-ANSI C compilers.
|
|
makefile.mc5: for Microsoft C 5.x under MS-DOS.
|
|
makefile.mc6: for Microsoft C 6.x and up under MS-DOS.
|
|
makefile.bcc: for Borland C (Turbo C) under MS-DOS.
|
|
makefile.icc: for Intel's Code Builder C under MS-DOS.
|
|
makefile.manx: for Manx Aztec C on Amigas.
|
|
makefile.sas: for SAS C on Amigas.
|
|
makcjpeg.st: project file for Atari ST/STE/TT Pure C or Turbo C.
|
|
makdjpeg.st: project file for Atari ST/STE/TT Pure C or Turbo C.
|
|
makljpeg.st: project file for Atari ST/STE/TT Pure C or Turbo C.
|
|
makefile.mms: for VAX/VMS systems with MMS.
|
|
makefile.vms: for VAX/VMS systems without MMS.
|
|
|
|
If you don't see a makefile for your system, we recommend starting from either
|
|
makefile.ansi or makefile.unix, depending on whether your compiler accepts
|
|
ANSI C or not. Actually you should start with makefile.ansi whenever your
|
|
compiler supports ANSI-style function definitions; you don't need full ANSI
|
|
compatibility. The difference between the two makefiles is that makefile.unix
|
|
preprocesses the source code to convert function definitions to old-style C.
|
|
(Our thanks to Peter Deutsch of Aladdin Enterprises for the ansi2knr program.)
|
|
|
|
If you don't know whether your compiler supports ANSI-style function
|
|
definitions, then take a look at ckconfig.c. It is a test program that will
|
|
help you figure out this fact, as well as some other facts you'll need in
|
|
later steps. You must compile and execute ckconfig.c by hand; the makefiles
|
|
don't provide any support for this. ckconfig.c may not compile the first try
|
|
(in fact, the whole idea is for it to fail if anything is going to). If you
|
|
get compile errors, fix them by editing ckconfig.c according to the directions
|
|
given in ckconfig.c. Once you get it to run, select a makefile according to
|
|
the advice it prints out, and make any other changes it recommends.
|
|
|
|
Look over the selected Makefile and adjust options as needed. In particular
|
|
you may want to change the CC and CFLAGS definitions. For instance, if you
|
|
are using GCC, set CC=gcc. If you had to use any compiler switches to get
|
|
ckconfig.c to work, make sure the same switches are in CFLAGS.
|
|
|
|
If you are on a system that doesn't use makefiles, you'll need to set up
|
|
project files (or whatever you do use) to compile all the source files and
|
|
link them into executable files cjpeg and djpeg. See the file lists in any of
|
|
the makefiles to find out which files go into each program. As a last resort,
|
|
you can make a batch script that just compiles everything and links it all
|
|
together; makefile.vms is an example of this (it's for VMS systems that have
|
|
no make-like utility).
|
|
|
|
|
|
STEP 2: EDIT JCONFIG.H
|
|
======================
|
|
|
|
Look over jconfig.h and adjust #defines to reflect the properties of your
|
|
system and C compiler. If you prefer, you can usually leave jconfig.h
|
|
unmodified and add -Dsymbol switches to the Makefile's CFLAGS definition.
|
|
(This is already done if you used a compiler-specific makefile in step 1.)
|
|
However, putting the switches in the Makefile is a bad idea if you are going
|
|
to incorporate the JPEG software into other programs --- you'd need to include
|
|
the same -D switches in the other programs' Makefiles. Better to change
|
|
jconfig.h.
|
|
|
|
If you have an ANSI-compliant C compiler, no changes should be necessary
|
|
except perhaps for RIGHT_SHIFT_IS_UNSIGNED and TWO_FILE_COMMANDLINE. For
|
|
older compilers other changes may be needed, depending on what ANSI features
|
|
are supported.
|
|
|
|
If you don't know enough about C programming to understand the questions in
|
|
jconfig.h, then use ckconfig.c to figure out what to change. (See description
|
|
of ckconfig.c in step 1.)
|
|
|
|
A note about TWO_FILE_COMMANDLINE: defining this selects the command line
|
|
syntax in which the input and output files are both named on the command line.
|
|
If it's not defined, the output image goes to standard output, and the input
|
|
can optionally come from standard input. You MUST use two-file style on any
|
|
system that doesn't cope well with binary data fed through stdin/stdout; this
|
|
is true for most MS-DOS compilers, for example. If you're not on a Unix
|
|
system, it's probably safest to assume you need two-file style. (But if your
|
|
compiler provides either the Posix-standard fdopen() library routine or a
|
|
Microsoft-compatible setmode() routine, you can use the Unix command line
|
|
style, by defining USE_FDOPEN or USE_SETMODE respectively.)
|
|
|
|
|
|
STEP 3: SELECT SYSTEM-DEPENDENT FILES
|
|
=====================================
|
|
|
|
A few places in the JPEG software are so system-dependent that we have to
|
|
provide several different implementations and let you select the one you need.
|
|
|
|
The only system-dependent file in the current version is jmemsys.c. This file
|
|
controls use of temporary files for big images that won't fit in main memory.
|
|
You'll notice there is no file named jmemsys.c in the distribution; you must
|
|
select one of the provided versions and copy, rename, or link it to jmemsys.c.
|
|
Here are the provided versions:
|
|
|
|
jmemansi.c This is a reasonably portable version that should
|
|
work on most ANSI and near-ANSI C compilers. It uses
|
|
the ANSI-standard library routine tmpfile(), which not
|
|
all non-ANSI systems have. On some systems tmpfile()
|
|
may put the temporary file in a non-optimal location;
|
|
if you don't like what it does, use jmemname.c.
|
|
|
|
jmemname.c This version constructs the temp file name by itself.
|
|
For anything except a Unix machine, you'll need to
|
|
configure the select_file_name() routine appropriately;
|
|
see the comments near the head of jmemname.c.
|
|
If you use this version, define NEED_SIGNAL_CATCHER
|
|
in jconfig.h or in the Makefile to make sure the temp
|
|
files are removed if the program is aborted.
|
|
|
|
jmemnobs.c (That stands for No Backing Store :-). This will
|
|
compile on almost any system, but it assumes you
|
|
have enough main memory or virtual memory to hold
|
|
the biggest images you need to work with.
|
|
|
|
jmemdos.c This should be used in most MS-DOS installations; see
|
|
the system-specific notes about MS-DOS for more info.
|
|
IMPORTANT: if you use this, also copy jmemdos.h to
|
|
jmemsys.h, replacing the standard version. ALSO,
|
|
include the assembly file jmemdosa.asm in the programs.
|
|
(This last is already done if you used one of the
|
|
supplied MS-DOS-specific makefiles.)
|
|
|
|
If you have plenty of (real or virtual) main memory, just use jmemnobs.c.
|
|
"Plenty" means at least ten bytes for every pixel in the largest images
|
|
you plan to process, so a lot of systems don't meet this criterion.
|
|
If yours doesn't, try jmemansi.c first. If that doesn't compile, you'll have
|
|
to use jmemname.c; be sure to adjust select_file_name() for local conditions.
|
|
You may also need to change unlink() to remove() in close_backing_store().
|
|
|
|
Except with jmemnobs.c, you need to adjust the #define DEFAULT_MAX_MEM to a
|
|
reasonable value for your system (either by editing jmemsys.c, or by adding
|
|
a -D switch to the Makefile). This value limits the amount of data space the
|
|
program will attempt to allocate. Code and static data space isn't counted,
|
|
so the actual memory needs for cjpeg or djpeg are typically 100 to 150Kb more
|
|
than the max-memory setting. Larger max-memory settings reduce the amount of
|
|
I/O needed to process a large image, but too large a value can result in
|
|
"insufficient memory" failures. On most Unix machines (and other systems with
|
|
virtual memory), just set DEFAULT_MAX_MEM to several million and forget it.
|
|
At the other end of the spectrum, for MS-DOS machines you probably can't go
|
|
much above 300K to 400K. (On MS-DOS the value refers to conventional memory;
|
|
extended/expanded memory is handled separately by jmemdos.c.)
|
|
|
|
|
|
STEP 4: MAKE
|
|
============
|
|
|
|
Now you should be able to "make" the software.
|
|
|
|
If you have trouble with missing system include files or inclusion of the
|
|
wrong ones, look at jinclude.h (or use ckconfig.c, if you are not a C expert).
|
|
|
|
If your compiler complains about big_sarray_control and big_barray_control
|
|
being undefined structures, you should be able to shut it up by adding
|
|
-DINCOMPLETE_TYPES_BROKEN to CFLAGS (or add #define INCOMPLETE_TYPES_BROKEN
|
|
to jconfig.h). If you don't have a getenv() library routine, define NO_GETENV.
|
|
|
|
There are a fair number of routines that do not use all of their parameters;
|
|
some compilers will issue warnings about this, which you can ignore. Any
|
|
other warning deserves investigation.
|
|
|
|
|
|
STEP 5: TEST
|
|
============
|
|
|
|
As a quick test of functionality we've included a small sample image in
|
|
several forms:
|
|
testorig.jpg A reduced section of the well-known Lenna picture.
|
|
testimg.ppm The output of djpeg testorig.jpg
|
|
testimg.gif The output of djpeg -gif testorig.jpg
|
|
testimg.jpg The output of cjpeg testimg.ppm
|
|
(The two .jpg files aren't identical since JPEG is lossy.) If you can
|
|
generate duplicates of the testimg.* files then you probably have working
|
|
programs.
|
|
|
|
With most of the makefiles, "make test" will perform the necessary
|
|
comparisons. If you started with makefile.ansi or makefile.unix, and you
|
|
defined TWO_FILE_COMMANDLINE, then change the makefile's test script to use
|
|
two-file syntax (i.e., delete the ">" character from the invocations of cjpeg
|
|
and djpeg). The other makefiles will work with either command-line syntax.
|
|
|
|
If you're using a makefile that doesn't provide the test option, run djpeg and
|
|
cjpeg by hand to generate testout.ppm, testout.gif, and testout.jpg, then
|
|
compare these to testimg.* with whatever binary file comparison tool you have.
|
|
The files should be bit-for-bit identical.
|
|
|
|
If the cjpeg test run fails with "Missing Huffman code table entry", it's a
|
|
good bet that you needed to define RIGHT_SHIFT_IS_UNSIGNED. Go back to step 2
|
|
and run ckconfig.c. (This is a good plan for any other test failure, too.)
|
|
|
|
If you are using Unix (one-file) command line style on a non-Unix system,
|
|
it's a good idea to check that binary I/O through stdin/stdout actually works.
|
|
You should get the same results from "djpeg <testorig.jpg >out.ppm" as from
|
|
"djpeg -outfile out.ppm testorig.jpg". Note that the non-Unix makefiles use
|
|
the latter style and therefore do not exercise stdin/stdout. If this test
|
|
fails, try recompiling jcmain.c & jdmain.c with USE_SETMODE and/or USE_FDOPEN.
|
|
|
|
If your choice of jmemsys.c was anything other than jmemnobs.c, you should
|
|
test that temporary-file usage works. Try "djpeg -gif -max 0 testorig.jpg"
|
|
and make sure its output matches testimg.gif. If you have any really large
|
|
images handy, try compressing them with -optimize and/or decompressing with
|
|
-gif to make sure your DEFAULT_MAX_MEM setting is not too large.
|
|
|
|
NOTE: this is far from an exhaustive test of the JPEG software; some modules,
|
|
such as 1-pass color quantization, are not exercised at all. It's just a quick
|
|
test to give you some confidence that you haven't missed something major.
|
|
|
|
|
|
STEP 6: INSTALLATION
|
|
====================
|
|
|
|
Once you're done with the above steps, you can install the software by copying
|
|
the executable files (cjpeg and djpeg) to wherever you normally install
|
|
programs. On Unix systems, you'll also want to put cjpeg.1 and djpeg.1 in the
|
|
corresponding manual directory. (The makefiles don't support this step since
|
|
there's such a wide variety of installation procedures on different systems.)
|
|
|
|
To learn to use the programs, read the file USAGE (or manual pages cjpeg(1)
|
|
and djpeg(1) on Unix). Note that the man pages cjpeg.1/djpeg.1 only describe
|
|
the Unix-style command line syntax; if you want to use these files with a
|
|
version that uses two-file command line syntax, you'll have to modify the text
|
|
accordingly. The USAGE file describes both styles.
|
|
|
|
|
|
OPTIMIZATION
|
|
============
|
|
|
|
Unless you own a Cray, you'll probably be interested in making the JPEG
|
|
software go as fast as possible. This section covers some machine-dependent
|
|
optimizations you may want to try. We suggest that before trying any of this,
|
|
you first get the basic installation to pass the self-test (step 5 above).
|
|
Repeat the self-test after any optimization to make sure that you haven't
|
|
broken anything.
|
|
|
|
The JPEG DCT routines perform a lot of multiplications. These multiplications
|
|
must yield 32-bit results, but none of their input values are more than 16
|
|
bits wide. On many machines, notably the 680x0 and 80x86 CPUs, a 16x16=>32
|
|
bit multiply instruction is faster than a full 32x32=>32 bit multiply.
|
|
Unfortunately there is no portable way to specify such a multiplication in C,
|
|
but some compilers can generate one when you use the right combination of
|
|
casts. See the MULTIPLY macro definitions in jfwddct.c and jrevdct.c.
|
|
If your compiler makes "int" be 32 bits and "short" be 16 bits, defining
|
|
SHORTxSHORT_32 is fairly likely to work. When experimenting with alternate
|
|
definitions, be sure to test not only whether the code still works (use the
|
|
self-test step), but also whether it is actually faster --- on some compilers,
|
|
alternate definitions may compute the right answer, yet be slower than the
|
|
default. Timing cjpeg on a large PPM input file is the best way to check
|
|
this, as the DCT will be the largest fraction of the runtime in that mode.
|
|
(Note: some of the distributed compiler-specific makefiles already contain
|
|
-D switches to select an appropriate MULTIPLY definition.)
|
|
|
|
If access to "short" arrays is slow on your machine, it may be a win to define
|
|
type DCTELEM as int rather than as JCOEF (which is normally defined as short).
|
|
This will cause the DCT routines to operate on int arrays instead of short
|
|
arrays. If shorts are slow and you have lots of memory to burn, you might
|
|
even make JCOEF itself be int.
|
|
|
|
If your compiler can compile function calls in-line, make sure the INLINE
|
|
macro in jconfig.h is defined as the keyword that marks a function
|
|
inline-able. Some compilers have a switch that tells the compiler to inline
|
|
any function it thinks is profitable (e.g., -finline-functions for gcc).
|
|
Enabling such a switch is likely to make the compiled code bigger but faster.
|
|
|
|
In general, it's worth trying the maximum optimization level of your compiler,
|
|
and experimenting with any optional optimizations such as loop unrolling.
|
|
(Unfortunately, far too many compilers have optimizer bugs ... be prepared to
|
|
back off if the code fails self-test.) If you do any experimentation along
|
|
these lines, please report the optimal settings to jpeg-info@uunet.uu.net so
|
|
we can mention them in future releases. Be sure to specify your machine and
|
|
compiler version.
|
|
|
|
|
|
OPTIONAL STUFF
|
|
==============
|
|
|
|
Progress monitor:
|
|
|
|
If you like, you can #define PROGRESS_REPORT (in jconfig.h or in the Makefile)
|
|
to enable display of percent-done progress reports. The routines provided in
|
|
jcmain.c/jdmain.c merely print percentages to stderr, but you can customize
|
|
them to do something fancier.
|
|
|
|
Utah RLE file format support:
|
|
|
|
We distribute the software with support for RLE image files (Utah Raster
|
|
Toolkit format) disabled, because the RLE support won't compile without the
|
|
Utah library. If you have URT version 3.0, you can enable RLE support as
|
|
follows:
|
|
1. #define RLE_SUPPORTED in jconfig.h or in the Makefile.
|
|
2. Add a -I option to CFLAGS in the Makefile for the directory
|
|
containing the URT .h files (typically the "include"
|
|
subdirectory of the URT distribution).
|
|
3. Add -L... -lrle to LDLIBS in the Makefile, where ... specifies
|
|
the directory containing the URT "librle.a" file (typically the
|
|
"lib" subdirectory of the URT distribution).
|
|
|
|
JPEG library:
|
|
|
|
If you want to incorporate the JPEG code as subroutines in a larger program,
|
|
we recommend that you make libjpeg.a, then link that into your surrounding
|
|
program. See file README for more info.
|
|
|
|
CAUTION: When you use the JPEG code as subroutines, we recommend that you make
|
|
any required configuration changes by modifying jconfig.h, not by adding -D
|
|
switches to the Makefile. Otherwise you must be sure to provide the same -D
|
|
switches when compiling any program that includes the JPEG .h files, to ensure
|
|
that the parameter structures are interpreted the same way. (This is only
|
|
critical for the first few symbols mentioned in jconfig.h, down through
|
|
NEED_FAR_POINTERS.)
|
|
|
|
Removing code:
|
|
|
|
If you need to make a smaller version of the JPEG software, some optional
|
|
functions can be removed at compile time. See the xxx_SUPPORTED #defines in
|
|
jconfig.h. If at all possible, we recommend that you leave in decoder support
|
|
for all valid JPEG files, to ensure that you can read anyone's output.
|
|
Restricting your encoder, or removing optional functions like block smoothing,
|
|
won't hurt compatibility. Taking out support for image file formats that you
|
|
don't use is the most painless way to make the programs smaller.
|
|
|
|
|
|
NOTES FOR SPECIFIC SYSTEMS
|
|
==========================
|
|
|
|
We welcome reports on changes needed for systems not mentioned here.
|
|
Submit 'em to jpeg-info@uunet.uu.net. Also, if ckconfig.c is wrong about
|
|
how to configure the JPEG software for your system, please let us know.
|
|
|
|
|
|
Amiga:
|
|
|
|
Makefiles are provided for Manx Aztec C and SAS C. I have also heard from
|
|
people who have compiled with the free DICE compiler, using makefile.ansi as a
|
|
starting point (set "CC= dcc" and "CFLAGS= -c -DAMIGA -DTWO_FILE_COMMANDLINE
|
|
-DNEED_SIGNAL_CATCHER" in the makefile). For all compilers, we recommend you
|
|
use jmemname.c as the system-dependent memory manager. Assuming you have
|
|
-DAMIGA in the makefile, jmemname.c will put temporary files in JPEGTMP:.
|
|
Change jmemname.c if you don't like this.
|
|
|
|
|
|
Atari:
|
|
|
|
The project files provided should work as-is with Pure C. For Turbo C, change
|
|
library filenames "PC..." to "TC..." in the project files for cjpeg.ttp and
|
|
djpeg.ttp. Don't forget to select a jmemsys.c file, see Step 3 (we recommend
|
|
jmemansi.c). Also adjust the DEFAULT_MAX_MEM setting --- you probably want it
|
|
to be a couple hundred K less than your normal free memory. Note that you
|
|
must make jpeg.lib before making cjpeg.ttp or cjpeg.ttp. You'll have to
|
|
perform the self-test (Step 5) by hand.
|
|
|
|
There is a bug in some older versions of the Turbo C library which causes the
|
|
space used by temporary files created with "tmpfile()" not to be freed after
|
|
an abnormal program exit. If you check your disk afterwards, you will find
|
|
cluster chains that are allocated but not used by a file. This should not
|
|
happen in cjpeg or djpeg, since we enable a signal catcher to explicitly close
|
|
temp files before exiting. But if you use the JPEG library with your own
|
|
code, be sure to supply a signal catcher, or else use a different
|
|
system-dependent memory manager.
|
|
|
|
|
|
Cray:
|
|
|
|
Should you be so fortunate as to be running JPEG on a Cray YMP, there is a
|
|
compiler bug in Cray's Standard C versions prior to 3.1. You'll need to
|
|
insert a line reading "#pragma novector" just before the loop
|
|
for (i = 1; i <= (int) htbl->bits[l]; i++)
|
|
huffsize[p++] = (char) l;
|
|
in fix_huff_tbl (in V4A, line 42 of jchuff.c and line 39 of jdhuff.c). The
|
|
usual symptom of not adding this line is a core-dump. See Cray's SPR 48222.
|
|
|
|
|
|
HP/Apollo DOMAIN:
|
|
|
|
With system release 10.4 or later, makefile.ansi should work OK. If you have
|
|
version 10.3.anything, you need to figure out whether you have the ANSI C
|
|
compiler (version 6.7 or later) and whether you've installed the ANSI C
|
|
include files (if so, the first line of <stdio.h> will mention ANSI C).
|
|
If you have the ANSI C compiler but not the ANSI C include files, use
|
|
makefile.ansi and add -DNONANSI_INCLUDES to CFLAGS. If you have both,
|
|
then makefile.ansi should work as is. If neither, use makefile.unix.
|
|
|
|
|
|
HP-UX:
|
|
|
|
If you have HP-UX 7.05 or later with the "software development" C compiler,
|
|
then you can use makefile.ansi. Add "-Aa" to the CFLAGS line in the makefile
|
|
to make the compiler work in ANSI mode. If you have a pre-7.05 system, or if
|
|
you are using the non-ANSI C compiler delivered with a minimum HP-UX 8.0
|
|
system, then you must use makefile.unix (and do NOT add -Aa). Also, adding
|
|
"-lmalloc" to LDLIBS is recommended if you have libmalloc.a (it seems not to
|
|
be present in minimum 8.0).
|
|
|
|
On HP 9000 series 800 machines, the HP C compiler is buggy in revisions prior
|
|
to A.08.07. If you get complaints about "not a typedef name", you'll have to
|
|
convert the code to K&R style (i.e., use makefile.unix).
|
|
|
|
|
|
Macintosh MPW:
|
|
|
|
We don't directly support MPW in the current release, but Larry Rosenstein
|
|
reports that the JPEG code can be ported without very much trouble. There's
|
|
useful notes and conversion scripts in his kit for porting PBMPLUS to MPW.
|
|
You can obtain the kit by FTP to ftp.apple.com, file /pub/lsr/pbmplus-port*.
|
|
|
|
|
|
Macintosh Think C:
|
|
|
|
You'll have to prepare project files for cjpeg and djpeg; we don't include
|
|
those in the distribution since they are not text files. The COBJECTS and
|
|
DOBJECTS lists in makefile.unix show which files should be included in each
|
|
project. Also add the ANSI and Unix C libraries in a separate segment. You
|
|
may need to divide the JPEG files into more than one segment; you can do this
|
|
pretty much as you please.
|
|
|
|
If you have Think C version 5.0 you need not modify jconfig.h; instead you
|
|
should turn on both the ANSI Settings and Language Extensions option buttons
|
|
(so that both __STDC__ and THINK_C are predefined). With version 4.0 you must
|
|
edit jconfig.h. (You can #define HAVE_STDC to do the right thing for all
|
|
options except const; you must also #define const.)
|
|
|
|
jcmain and jdmain are set up to provide the usual command-line interface
|
|
by means of Think's ccommand() library routine. A more Mac-like interface
|
|
is in the works.
|
|
|
|
|
|
MS-DOS, generic comments:
|
|
|
|
The JPEG code is designed to be compiled with 80x86 "small" or "medium" memory
|
|
models (i.e., data pointers are 16 bits unless explicitly declared "far"; code
|
|
pointers can be either size). You should be able to use small model to
|
|
compile cjpeg or djpeg by itself, but you will probably have to go to medium
|
|
model if you include the JPEG code in a larger application. This shouldn't
|
|
hurt performance much. You *will* take a noticeable performance hit if you
|
|
compile in a large-data memory model, and you should avoid "huge" model if at
|
|
all possible. Be sure that NEED_FAR_POINTERS is defined by jconfig.h or by
|
|
the Makefile if you use a small-data model; be sure it is NOT defined if you
|
|
use a large-data memory model. (As distributed, jconfig.h defines
|
|
NEED_FAR_POINTERS if MSDOS is defined.)
|
|
|
|
The DOS-specific memory manager, jmemdos.c, should be used if possible.
|
|
(Be sure to install jmemdos.h and jmemdosa.asm along with it.) If you
|
|
can't use jmemdos.c for some reason --- for example, because you don't have
|
|
a Microsoft-compatible assembler to assemble jmemdosa.asm --- you'll have
|
|
to fall back to jmemansi.c or jmemname.c. IMPORTANT: if you use either of
|
|
the latter two files, you will have to compile in a large-data memory model
|
|
in order to get the right stdio library. Too bad.
|
|
|
|
None of the above advice applies if you are using a 386 flat-memory-space
|
|
environment, such as DJGPP or Watcom C. (And you should use one if you have
|
|
it, as performance will be much better than 8086-compatible code!) For
|
|
flat-memory-space compilers, do NOT define NEED_FAR_POINTERS, and do NOT use
|
|
jmemdos.c. Use jmemnobs.c if the environment supplies adequate virtual
|
|
memory, otherwise use jmemansi.c or jmemname.c.
|
|
|
|
Most MS-DOS compilers treat stdin/stdout as text files, so you must use
|
|
two-file command line style. But if your compiler has either fdopen() or
|
|
setmode(), you can use one-file style if you like. To do this, define
|
|
USE_FDOPEN or USE_SETMODE so that stdin/stdout will be set to binary mode.
|
|
(USE_SETMODE seems to work with more DOS compilers than USE_FDOPEN.) You
|
|
should test that I/O through stdin/stdout produces the same results as I/O
|
|
to explicitly named files... the "make test" procedures in the DOS-specific
|
|
makefiles do NOT use stdin/stdout.
|
|
|
|
If you add more switches to CFLAGS in the DOS-specific makefiles, you are
|
|
likely to run up against DOS' 128-byte command line length limit. In that
|
|
case, remove some "-Dsymbol" switches from CFLAGS and instead put
|
|
corresponding "#define symbol" lines at the head of jinclude.h.
|
|
|
|
|
|
MS-DOS, Borland C:
|
|
|
|
Be sure to convert all the source files to DOS text format (CR/LF newlines).
|
|
Although Borland C will often work OK with unmodified Unix (LF newlines)
|
|
source files, sometimes it will give bogus compile errors.
|
|
"Illegal character '#'" is the most common such error.
|
|
|
|
Some versions of Borland's MAKE erroneously display the warning message about
|
|
creating jmemsys.c, even after you have done so. If this happens to you,
|
|
delete the four lines beginning with "jmemsys.c:" from the Makefile.
|
|
|
|
If you want one-file command line style, define USE_SETMODE. fdopen() does
|
|
not work correctly.
|
|
|
|
|
|
MS-DOS, DJGPP:
|
|
|
|
Use makefile.ansi and jmemnobs.c, and put "-UMSDOS" in CFLAGS to undo the
|
|
compiler's automatic definition of MSDOS. Also put either "-DUSE_SETMODE" or
|
|
"-DTWO_FILE_COMMANDLINE" in CFLAGS, depending on whether you prefer one-file
|
|
or two-file command line style. You'll also need to put the object-file lists
|
|
into response files in order to circumvent DOS's 128-byte command line length
|
|
limit at the final linking step.
|
|
|
|
|
|
MS-DOS, Microsoft C:
|
|
|
|
Old versions of MS C fail with an "out of macro expansion space" error
|
|
because they can't cope with the macro TRACEMS8 (defined in jpegdata.h).
|
|
If this happens to you, the easiest solution is to change TRACEMS8 to
|
|
expand to nothing. You'll lose the ability to dump out JPEG coefficient
|
|
tables with djpeg -debug -debug, but at least you can compile.
|
|
|
|
Original MS C 6.0 is buggy; it compiles incorrect code unless you turn off
|
|
optimization (remove -O from CFLAGS). That problem seems to have been fixed
|
|
in 6.00A and later versions. 6.00A still generates a bogus "conditional
|
|
expression is constant" warning in jrdppm.c, but the emitted code seems OK.
|
|
|
|
If you want one-file command line style, define USE_SETMODE. fdopen() does
|
|
not work correctly, at least not in 6.00A.
|
|
|
|
|
|
SGI:
|
|
|
|
Use makefile.ansi, but set "AR2= ar -ts" rather than "AR2= ranlib". Also
|
|
make any changes recommended by ckconfig.c.
|
|
|
|
|
|
Sun:
|
|
|
|
Don't forget to add -DBSD to CFLAGS. If you are using GCC on SunOS 4.0.1 or
|
|
earlier, you will need to add -DNONANSI_INCLUDES to CFLAGS (your compiler may
|
|
be ANSI, but your system include files aren't). I've gotten conflicting
|
|
reports on whether this is still necessary on SunOS 4.1 or later.
|