JPEGView/Independent JPEG Group/install.doc

INSTALLATION INSTRUCTIONS for the Independent JPEG Group's JPEG software

Copyright (C) 1991-1994, Thomas G. Lane.
This file is part of the Independent JPEG Group's software.
For conditions of distribution and use, see the accompanying README file.


This file explains how to configure and install the IJG 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 complicated.  We have provided shortcuts to simplify
the task on common systems.  But in any case, you will need at least a little
familiarity with C programming and program build procedures for your system.

If you are only using this software as part of a larger program, the larger
program's installation procedure may take care of configuring the IJG code.
For example, Ghostscript's installation script will configure the IJG code.
You don't need to read this file if you just want to compile Ghostscript.

In this alpha-test release, the "configure" script is brand new and should not
be trusted.  Please try it, if you are on a Unix machine; but please also read
the hand-installation instructions, and verify that configure produced
reasonable Makefile and jconfig.h files.  Also, I have not been able to test
the canned makefiles and jconfig files for non-Unix machines.  Please report
any problems to jpeg-info@uunet.uu.net.


TABLE OF CONTENTS
-----------------

Before you start
Configuring the software:
	using the automatic "configure" script
	using one of the supplied jconfig and makefile files
	by hand
Building the software
Testing the software
Installing the software
Optional stuff
Optimization
Hints for specific systems


BEFORE YOU START
================

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 a potential for error if you needed to convert the
files to the local standard text file format (for example, if you are on
MS-DOS you may have converted LF end-of-line to CR/LF).  You must apply
such 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.

Please check the last section of this file to see if there are hints for the
specific machine or compiler you are using.


CONFIGURING THE SOFTWARE
========================

To configure the IJG code for your system, you need to create two files:
  * jconfig.h: contains values for system-dependent #define symbols.
  * Makefile: controls the compilation process.
(On a non-Unix machine, you may create "project files" or some other
substitute for a Makefile.  jconfig.h is needed in any environment.)

We provide three different ways to generate these files:
  * On a Unix system, you can just run the "configure" script.
  * We provide sample jconfig files and makefiles for popular machines;
    if your machine matches one of the samples, just copy the right sample
    files to jconfig.h and Makefile.
  * If all else fails, read the instructions below and make your own files.


Configuring the software using the automatic "configure" script
---------------------------------------------------------------

If you are on a Unix machine, you can just type
	./configure
and let the configure script construct appropriate configuration files.
If you're using "csh" on an old version of System V, you might need to type
	sh configure
instead to prevent csh from trying to execute configure itself.
Expect configure to run for a few minutes, particularly on slower machines;
it works by compiling a series of test programs.

Configure was created with GNU Autoconf and it follows the usual conventions
for GNU configure scripts.  It makes a few assumptions that you may want to
override.  You can do this by providing optional switches to configure:

* Configure will use gcc (GNU C compiler) if it's available, otherwise cc.
To force a particular compiler to be selected, use the CC option, for example
	./configure CC='cc'
The same method can be used to include any unusual compiler switches.
For example, on HP-UX you probably want to say
	./configure CC='cc -Aa'
to get HP's compiler to run in ANSI mode.

* Configure will set up the makefile so that "make install" will install files
into /usr/local/bin, /usr/local/man, etc.  You can specify an installation
prefix other than "/usr/local" by giving configure the option "--prefix=PATH".

* If you don't have a lot of swap space, you may need to enable the IJG
software's internal virtual memory mechanism.  To do this, give the option
"--with-maxmem=N" where N is the default maxmemory limit in megabytes.
This is discussed in more detail under "Selecting a memory manager", below.
You probably don't need to worry about this on reasonably-sized Unix machines,
unless you plan to process very large images.

Configure has some other features that are useful if you are cross-compiling
or working in a network of multiple machine types; but if you need those
features, you probably already know how to use them.


Configuring the software using one of the supplied jconfig and makefile files
-----------------------------------------------------------------------------

If you have one of these systems, you can just use the provided configuration
files:

Makefile	jconfig file	System and/or compiler

makefile.manx	jconfig.manx	Amiga, Manx Aztec C
makefile.sas	jconfig.sas	Amiga, SAS C
mak*jpeg.st	jconfig.st	Atari ST/STE/TT, Pure C or Turbo C
makefile.bcc	jconfig.bcc	MS-DOS, Borland C (Turbo C)
makefile.mc6	jconfig.mc6	MS-DOS, Microsoft C version 6.x and up
makefile.mms	jconfig.vms	VAX/VMS, with MMS software
makefile.vms	jconfig.vms	VAX/VMS, without MMS software

Copy the proper jconfig file to jconfig.h and the makefile to Makefile,
or whatever your system uses as the standard makefile name.  (For the
Atari, we provide three project files; see the Atari hints below.)

[Note to alpha testers: please double-check the contents of these files and
report success or failure.  Contributions of more system-specific files
are welcome.]


Configuring the software by hand
--------------------------------

First, generate a jconfig.h file.  If you are moderately familiar with C,
the comments in jconfig.doc should be enough information to do this; just
copy jconfig.doc to jconfig.h and edit it appropriately.  Otherwise, you may
prefer to use the ckconfig.c program.  You will need to compile and execute
ckconfig.c by hand --- we hope you know at least enough to do that.
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, it will write a suitable jconfig.h file, and will also
print out some advice about which makefile to use.

You may also want to look at the canned jconfig files, if there is one for a
system similar to yours.

Second, select a makefile and copy it to Makefile (or whatever your system
uses as the standard makefile name).  The most generic makefiles we provide
are
	makefile.ansi:	if your C compiler supports function prototypes
	makefile.unix:	if not.
(You have function prototypes if ckconfig.c put "#define HAVE_PROTOTYPES"
in jconfig.h.)  You may want to start from one of the other makefiles if
there is one for a system similar to yours.

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.  Note that
the provided makefiles all make a "library" file libjpeg first, but you
don't have to do that if you don't want to; the file lists identify which
source files are actually needed for compression, decompression, or both.
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).

Here are comments about some specific configuration decisions you'll
need to make:

Command line style
------------------

cjpeg and djpeg can use a Unix-like command line style which supports
redirection and piping, like this:
	cjpeg inputfile >outputfile
	cjpeg <inputfile >outputfile
	source program | cjpeg >outputfile
The simpler "two file" command line style is just
	cjpeg inputfile outputfile
You may prefer the two-file style, particularly if you don't have pipes.

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 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.)

To use the two-file style, make jconfig.h say "#define TWO_FILE_COMMANDLINE".

Selecting a memory manager
--------------------------

The IJG code is capable of working on images that are too big to fit in main
memory; data is swapped out to temporary files as necessary.  However, the
code to do this is rather system-dependent.  We provide four different
memory managers:

* jmemansi.c	This version 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 creates named temporary files.  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 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 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, define USE_MSDOS_MEMMGR in
		jconfig.h, and include the assembly file jmemdosa.asm in the
		programs.  The supplied makefiles and jconfig files for
		MS-DOS compilers already do both.

To use a particular memory manager, change the SYSDEPMEM variable in your
makefile to equal the corresponding object file name (for example, jmemansi.o
or jmemansi.obj for jmemansi.c).

If you have plenty of (real or virtual) main memory, just use jmemnobs.c.
"Plenty" means about 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 DEFAULT_MAX_MEM setting to a
reasonable value for your system (either by adding a #define for
DEFAULT_MAX_MEM to jconfig.h, 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.)


BUILDING THE SOFTWARE
=====================

Now you should be able to compile the software.  Just say "make" (or
whatever's necessary to start the compilation).  Have a cup of coffee.

Here are some things that could go wrong:

If your compiler complains about undefined structures, you should be able to
shut it up by putting "#define INCOMPLETE_TYPES_BROKEN" in jconfig.h.

If you have trouble with missing system include files or inclusion of the
wrong ones, read jinclude.h.  This shouldn't happen if you used configure
or ckconfig.c to set up 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.

Also see the system-specific hints, below.


TESTING THE SOFTWARE
====================

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'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 the
configuration step 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 makefiles all
use the latter style and therefore do not exercise stdin/stdout!  If this
check fails, try recompiling cjpeg.c and djpeg.c with USE_SETMODE or
USE_FDOPEN.  If it still doesn't work, better use two-file style.

If you chose a memory manager 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.


INSTALLING THE SOFTWARE
=======================

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 man-page directory.  The canned makefiles don't support this
step since there's such a wide variety of installation procedures on
different systems.

If you generated a Makefile with the "configure" script, you can just say
	make install
to install the cjpeg and djpeg programs and their man pages into the standard
places.  (You'll probably need to be root to do this.)  We recommend first
saying
	make -n install
to see where configure thought the files should go.  You may need to edit the
Makefile, particularly if your system's conventions for man page filenames
don't match what configure expects.

If you want to install the library file libjpeg.a and the include files j*.h
(for use in compiling other programs besides cjpeg/djpeg), then say
	make install-lib


OPTIONAL STUFF
==============

Progress monitor:

If you like, you can #define PROGRESS_REPORT (in jconfig.h) to enable display
of percent-done progress reports.  The routines provided in cjpeg.c/djpeg.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.
	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).

[Note: RLE support is not currently present in v5.  Any volunteers to make
it work again?]

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 and jmorecfg.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.  Taking out support for image file formats that you don't use is the
most painless way to make the programs smaller.


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.
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), 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 jconfig files already contain
#define 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 JCOEF as int rather than short.  This will cost a good deal of
memory though, particularly in some multi-pass modes, so don't do it unless
you have memory to burn and short is REALLY slow.

If your compiler can compile function calls in-line, make sure the INLINE
macro in jmorecfg.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.


HINTS FOR SPECIFIC SYSTEMS
==========================

We welcome reports on changes needed for systems not mentioned here.  Submit
'em to jpeg-info@uunet.uu.net.  Also, if configure or ckconfig.c is wrong
about how to configure the JPEG software for your system, please let us know.


Amiga:

SAS C 6.50 reportedly is too buggy to compile the IJG code properly.
A patch to update to 6.51 is available from SAS or AmiNet FTP sites.


Atari:
 
Copy the project files makcjpeg.st, makdjpeg.st, and makljpeg.st to cjpeg.prj,
djpeg.prj, and libjpeg.prj respectively.  The project files should work as-is
with Pure C.  For Turbo C, change library filenames "PC..." to "TC..." in
cjpeg.prj and djpeg.prj.  Note that libjpeg.prj selects jmemansi.c as the
recommended memory manager.  You'll probably want to adjust the
DEFAULT_MAX_MEM setting --- you want it to be a couple hundred K less than
your normal free memory.  Put "#define DEFAULT_MAX_MEM nnnn" into jconfig.h
to do this.

Note that you must make libjpeg.lib before making cjpeg.ttp or djpeg.ttp.
You'll have to perform the self-test 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.
[This bug may or may not still occur with V5; can anyone test it?]


HP-UX:

If you have HP-UX 7.05 or later with the "software development" C compiler,
you should run the compiler in ANSI mode.  If using the configure script,
say
	./configure CC='cc -Aa'
(or -Ae if you prefer).  If configuring by hand, use makefile.ansi and add
"-Aa" to the CFLAGS line in the makefile.

If you have a pre-7.05 system, or if you are using the non-ANSI C compiler
delivered with a minimum HP-UX system, then you must use makefile.unix
(and do NOT add -Aa); or just run configure without the CC option.

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
use makefile.unix, or run configure without the CC option.


Macintosh MPW:

We don't directly support MPW in the current release, but Larry Rosenstein
ported an earlier version of the IJG code 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:

The supplied user-interface files (cjpeg.c and djpeg.c) are set up to provide
a Unix-style command line interface.  You can use this interface on the Mac
by means of Think's ccommand() library routine.  However, a much better
Mac-style user interface has been prepared by Jim Brunner.  You can obtain
the additional source code needed for that user interface by FTP to
sumex-aim.stanford.edu, file /info-mac/source/c/jpeg-convert.hqx.  Jim's
documentation also includes more detailed build instructions for Think C.
[I hope someone will update JPEG Convert to work with V5...]  If you want to
build the minimal command line version, proceed as follows:

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.  Use the file lists
in any of the supplied makefiles as a guide.  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; we recommend dividing compression and decompression
modules.


MIPS R3000:

MIPS's cc version 1.31 has a rather nasty optimization bug.  Don't use -O
if you have that compiler version.  (Use "cc -V" to check the version.)
Note that the R3000 chip is found in workstations from DEC and others.


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 in
jconfig.h if you use a small-data model; be sure it is NOT defined if you use
a large-data memory model.  (It is defined in the supplied jconfig files for
Borland and Microsoft C.)

The DOS-specific memory manager, jmemdos.c, should be used if possible.
It needs some assembly-code routines which are in jmemdosa.asm; make sure
your makefile assembles that file and includes it in the library.
When using jmemdos.c, jconfig.h must define USE_MSDOS_MEMMGR and must set
MAX_ALLOC_CHUNK to less than 64K (65520L is a typical value).

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.  You'll probably still need to
set MAX_ALLOC_CHUNK in jconfig.h, because most DOS C libraries won't malloc()
more than 64K at a time.  IMPORTANT: if you use jmemansi.c or jmemname.c, 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 supplied
makefiles do NOT use stdin/stdout.


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.

If you want one-file command line style, just undefine TWO_FILE_COMMANDLINE.
jconfig.bcc includes #define USE_SETMODE.  (fdopen does not work correctly.)


MS-DOS, DJGPP:

Use makefile.ansi and jmemnobs.c.  Define either USE_SETMODE or
TWO_FILE_COMMANDLINE in jconfig.h, depending on whether you prefer one-file
or two-file command line style.  You'll 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.

[There should probably be a set of canned config files for DJGPP.
Any volunteers?]


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 jerror.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 very buggy; it compiles incorrect code unless you turn
off optimization entirely (remove -O from CFLAGS).  6.00A is better, but it
still generates bad code if you enable loop optimizations (-Ol or -Ox).

If you want one-file command line style, just undefine TWO_FILE_COMMANDLINE.
jconfig.mc6 includes #define USE_SETMODE.  (fdopen does not work correctly.)


SGI:

Set "AR2= ar -ts" rather than "AR2= ranlib" in the Makefile.  If you are
using configure, you should say
	./configure RANLIB='ar -ts'