update latest
[framework/multimedia/libjpeg8.git] / install.txt
1 INSTALLATION INSTRUCTIONS for the Independent JPEG Group's JPEG software
2
3 Copyright (C) 1991-2010, Thomas G. Lane, Guido Vollbeding.
4 This file is part of the Independent JPEG Group's software.
5 For conditions of distribution and use, see the accompanying README file.
6
7
8 This file explains how to configure and install the IJG software.  We have
9 tried to make this software extremely portable and flexible, so that it can be
10 adapted to almost any environment.  The downside of this decision is that the
11 installation process is complicated.  We have provided shortcuts to simplify
12 the task on common systems.  But in any case, you will need at least a little
13 familiarity with C programming and program build procedures for your system.
14
15 If you are only using this software as part of a larger program, the larger
16 program's installation procedure may take care of configuring the IJG code.
17 For example, Ghostscript's installation script will configure the IJG code.
18 You don't need to read this file if you just want to compile Ghostscript.
19
20 If you are on a Unix machine, you may not need to read this file at all.
21 Try doing
22         ./configure
23         make
24         make test
25 If that doesn't complain, do
26         make install
27 (better do "make -n install" first to see if the makefile will put the files
28 where you want them).  Read further if you run into snags or want to customize
29 the code for your system.
30
31
32 TABLE OF CONTENTS
33 -----------------
34
35 Before you start
36 Configuring the software:
37         using the automatic "configure" script
38         using one of the supplied jconfig and makefile files
39         by hand
40 Building the software
41 Testing the software
42 Installing the software
43 Optional stuff
44 Optimization
45 Hints for specific systems
46
47
48 BEFORE YOU START
49 ================
50
51 Before installing the software you must unpack the distributed source code.
52 Since you are reading this file, you have probably already succeeded in this
53 task.  However, there is a potential for error if you needed to convert the
54 files to the local standard text file format (for example, if you are on
55 MS-DOS you may have converted LF end-of-line to CR/LF).  You must apply
56 such conversion to all the files EXCEPT those whose names begin with "test".
57 The test files contain binary data; if you change them in any way then the
58 self-test will give bad results.
59
60 Please check the last section of this file to see if there are hints for the
61 specific machine or compiler you are using.
62
63
64 CONFIGURING THE SOFTWARE
65 ========================
66
67 To configure the IJG code for your system, you need to create two files:
68   * jconfig.h: contains values for system-dependent #define symbols.
69   * Makefile: controls the compilation process.
70 (On a non-Unix machine, you may create "project files" or some other
71 substitute for a Makefile.  jconfig.h is needed in any environment.)
72
73 We provide three different ways to generate these files:
74   * On a Unix system, you can just run the "configure" script.
75   * We provide sample jconfig files and makefiles for popular machines;
76     if your machine matches one of the samples, just copy the right sample
77     files to jconfig.h and Makefile.
78   * If all else fails, read the instructions below and make your own files.
79
80
81 Configuring the software using the automatic "configure" script
82 ---------------------------------------------------------------
83
84 If you are on a Unix machine, you can just type
85         ./configure
86 and let the configure script construct appropriate configuration files.
87 If you're using "csh" on an old version of System V, you might need to type
88         sh configure
89 instead to prevent csh from trying to execute configure itself.
90 Expect configure to run for a few minutes, particularly on slower machines;
91 it works by compiling a series of test programs.
92
93 Configure was created with GNU Autoconf and it follows the usual conventions
94 for GNU configure scripts.  It makes a few assumptions that you may want to
95 override.  You can do this by providing optional switches to configure:
96
97 * Configure will build both static and shared libraries, if possible.
98 If you want to build libjpeg only as a static library, say
99         ./configure --disable-shared
100 If you want to build libjpeg only as a shared library, say
101         ./configure --disable-static
102 Configure uses GNU libtool to take care of system-dependent shared library
103 building methods.
104
105 * Configure will use gcc (GNU C compiler) if it's available, otherwise cc.
106 To force a particular compiler to be selected, use the CC option, for example
107         ./configure CC='cc'
108 The same method can be used to include any unusual compiler switches.
109 For example, on HP-UX you probably want to say
110         ./configure CC='cc -Aa'
111 to get HP's compiler to run in ANSI mode.
112
113 * The default CFLAGS setting is "-g" for non-gcc compilers, "-g -O2" for gcc.
114 You can override this by saying, for example,
115         ./configure CFLAGS='-O2'
116 if you want to compile without debugging support.
117
118 * Configure will set up the makefile so that "make install" will install files
119 into /usr/local/bin, /usr/local/man, etc.  You can specify an installation
120 prefix other than "/usr/local" by giving configure the option "--prefix=PATH".
121
122 * If you don't have a lot of swap space, you may need to enable the IJG
123 software's internal virtual memory mechanism.  To do this, give the option
124 "--enable-maxmem=N" where N is the default maxmemory limit in megabytes.
125 This is discussed in more detail under "Selecting a memory manager", below.
126 You probably don't need to worry about this on reasonably-sized Unix machines,
127 unless you plan to process very large images.
128
129 Configure has some other features that are useful if you are cross-compiling
130 or working in a network of multiple machine types; but if you need those
131 features, you probably already know how to use them.
132
133
134 Configuring the software using one of the supplied jconfig and makefile files
135 -----------------------------------------------------------------------------
136
137 If you have one of these systems, you can just use the provided configuration
138 files:
139
140 Makefile        jconfig file    System and/or compiler
141
142 makefile.manx   jconfig.manx    Amiga, Manx Aztec C
143 makefile.sas    jconfig.sas     Amiga, SAS C
144 makeproj.mac    jconfig.mac     Apple Macintosh, Metrowerks CodeWarrior
145 mak*jpeg.st     jconfig.st      Atari ST/STE/TT, Pure C or Turbo C
146 makefile.bcc    jconfig.bcc     MS-DOS or OS/2, Borland C
147 makefile.dj     jconfig.dj      MS-DOS, DJGPP (Delorie's port of GNU C)
148 makefile.mc6    jconfig.mc6     MS-DOS, Microsoft C (16-bit only)
149 makefile.wat    jconfig.wat     MS-DOS, OS/2, or Windows NT, Watcom C
150 makefile.vc     jconfig.vc      Windows NT/95, MS Visual C++
151 make*.vc6       jconfig.vc      Windows NT/95, MS Visual C++ 6
152 make*.v10       jconfig.vc      Windows NT/95, MS Visual C++ 2010 (v10)
153 makefile.mms    jconfig.vms     Digital VMS, with MMS software
154 makefile.vms    jconfig.vms     Digital VMS, without MMS software
155
156 Copy the proper jconfig file to jconfig.h and the makefile to Makefile (or
157 whatever your system uses as the standard makefile name).  For more info see
158 the appropriate system-specific hints section near the end of this file.
159
160
161 Configuring the software by hand
162 --------------------------------
163
164 First, generate a jconfig.h file.  If you are moderately familiar with C,
165 the comments in jconfig.txt should be enough information to do this; just
166 copy jconfig.txt to jconfig.h and edit it appropriately.  Otherwise, you may
167 prefer to use the ckconfig.c program.  You will need to compile and execute
168 ckconfig.c by hand --- we hope you know at least enough to do that.
169 ckconfig.c may not compile the first try (in fact, the whole idea is for it
170 to fail if anything is going to).  If you get compile errors, fix them by
171 editing ckconfig.c according to the directions given in ckconfig.c.  Once
172 you get it to run, it will write a suitable jconfig.h file, and will also
173 print out some advice about which makefile to use.
174
175 You may also want to look at the canned jconfig files, if there is one for a
176 system similar to yours.
177
178 Second, select a makefile and copy it to Makefile (or whatever your system
179 uses as the standard makefile name).  The most generic makefiles we provide
180 are
181         makefile.ansi:  if your C compiler supports function prototypes
182         makefile.unix:  if not.
183 (You have function prototypes if ckconfig.c put "#define HAVE_PROTOTYPES"
184 in jconfig.h.)  You may want to start from one of the other makefiles if
185 there is one for a system similar to yours.
186
187 Look over the selected Makefile and adjust options as needed.  In particular
188 you may want to change the CC and CFLAGS definitions.  For instance, if you
189 are using GCC, set CC=gcc.  If you had to use any compiler switches to get
190 ckconfig.c to work, make sure the same switches are in CFLAGS.
191
192 If you are on a system that doesn't use makefiles, you'll need to set up
193 project files (or whatever you do use) to compile all the source files and
194 link them into executable files cjpeg, djpeg, jpegtran, rdjpgcom, and wrjpgcom.
195 See the file lists in any of the makefiles to find out which files go into
196 each program.  Note that the provided makefiles all make a "library" file
197 libjpeg first, but you don't have to do that if you don't want to; the file
198 lists identify which source files are actually needed for compression,
199 decompression, or both.  As a last resort, you can make a batch script that
200 just compiles everything and links it all together; makefile.vms is an example
201 of this (it's for VMS systems that have no make-like utility).
202
203 Here are comments about some specific configuration decisions you'll
204 need to make:
205
206 Command line style
207 ------------------
208
209 These programs can use a Unix-like command line style which supports
210 redirection and piping, like this:
211         cjpeg inputfile >outputfile
212         cjpeg <inputfile >outputfile
213         source program | cjpeg >outputfile
214 The simpler "two file" command line style is just
215         cjpeg inputfile outputfile
216 You may prefer the two-file style, particularly if you don't have pipes.
217
218 You MUST use two-file style on any system that doesn't cope well with binary
219 data fed through stdin/stdout; this is true for some MS-DOS compilers, for
220 example.  If you're not on a Unix system, it's safest to assume you need
221 two-file style.  (But if your compiler provides either the Posix-standard
222 fdopen() library routine or a Microsoft-compatible setmode() routine, you
223 can safely use the Unix command line style, by defining USE_FDOPEN or
224 USE_SETMODE respectively.)
225
226 To use the two-file style, make jconfig.h say "#define TWO_FILE_COMMANDLINE".
227
228 Selecting a memory manager
229 --------------------------
230
231 The IJG code is capable of working on images that are too big to fit in main
232 memory; data is swapped out to temporary files as necessary.  However, the
233 code to do this is rather system-dependent.  We provide five different
234 memory managers:
235
236 * jmemansi.c    This version uses the ANSI-standard library routine tmpfile(),
237                 which not all non-ANSI systems have.  On some systems
238                 tmpfile() may put the temporary file in a non-optimal
239                 location; if you don't like what it does, use jmemname.c.
240
241 * jmemname.c    This version creates named temporary files.  For anything
242                 except a Unix machine, you'll need to configure the
243                 select_file_name() routine appropriately; see the comments
244                 near the head of jmemname.c.  If you use this version, define
245                 NEED_SIGNAL_CATCHER in jconfig.h to make sure the temp files
246                 are removed if the program is aborted.
247
248 * jmemnobs.c    (That stands for No Backing Store :-).)  This will compile on
249                 almost any system, but it assumes you have enough main memory
250                 or virtual memory to hold the biggest images you work with.
251
252 * jmemdos.c     This should be used with most 16-bit MS-DOS compilers.
253                 See the system-specific notes about MS-DOS for more info.
254                 IMPORTANT: if you use this, define USE_MSDOS_MEMMGR in
255                 jconfig.h, and include the assembly file jmemdosa.asm in the
256                 programs.  The supplied makefiles and jconfig files for
257                 16-bit MS-DOS compilers already do both.
258
259 * jmemmac.c     Custom version for Apple Macintosh; see the system-specific
260                 notes for Macintosh for more info.
261
262 To use a particular memory manager, change the SYSDEPMEM variable in your
263 makefile to equal the corresponding object file name (for example, jmemansi.o
264 or jmemansi.obj for jmemansi.c).
265
266 If you have plenty of (real or virtual) main memory, just use jmemnobs.c.
267 "Plenty" means about ten bytes for every pixel in the largest images
268 you plan to process, so a lot of systems don't meet this criterion.
269 If yours doesn't, try jmemansi.c first.  If that doesn't compile, you'll have
270 to use jmemname.c; be sure to adjust select_file_name() for local conditions.
271 You may also need to change unlink() to remove() in close_backing_store().
272
273 Except with jmemnobs.c or jmemmac.c, you need to adjust the DEFAULT_MAX_MEM
274 setting to a reasonable value for your system (either by adding a #define for
275 DEFAULT_MAX_MEM to jconfig.h, or by adding a -D switch to the Makefile).
276 This value limits the amount of data space the program will attempt to
277 allocate.  Code and static data space isn't counted, so the actual memory
278 needs for cjpeg or djpeg are typically 100 to 150Kb more than the max-memory
279 setting.  Larger max-memory settings reduce the amount of I/O needed to
280 process a large image, but too large a value can result in "insufficient
281 memory" failures.  On most Unix machines (and other systems with virtual
282 memory), just set DEFAULT_MAX_MEM to several million and forget it.  At the
283 other end of the spectrum, for MS-DOS machines you probably can't go much
284 above 300K to 400K.  (On MS-DOS the value refers to conventional memory only.
285 Extended/expanded memory is handled separately by jmemdos.c.)
286
287
288 BUILDING THE SOFTWARE
289 =====================
290
291 Now you should be able to compile the software.  Just say "make" (or
292 whatever's necessary to start the compilation).  Have a cup of coffee.
293
294 Here are some things that could go wrong:
295
296 If your compiler complains about undefined structures, you should be able to
297 shut it up by putting "#define INCOMPLETE_TYPES_BROKEN" in jconfig.h.
298
299 If you have trouble with missing system include files or inclusion of the
300 wrong ones, read jinclude.h.  This shouldn't happen if you used configure
301 or ckconfig.c to set up jconfig.h.
302
303 There are a fair number of routines that do not use all of their parameters;
304 some compilers will issue warnings about this, which you can ignore.  There
305 are also a few configuration checks that may give "unreachable code" warnings.
306 Any other warning deserves investigation.
307
308 If you don't have a getenv() library routine, define NO_GETENV.
309
310 Also see the system-specific hints, below.
311
312
313 TESTING THE SOFTWARE
314 ====================
315
316 As a quick test of functionality we've included a small sample image in
317 several forms:
318         testorig.jpg    Starting point for the djpeg tests.
319         testimg.ppm     The output of djpeg testorig.jpg
320         testimg.bmp     The output of djpeg -bmp -colors 256 testorig.jpg
321         testimg.jpg     The output of cjpeg testimg.ppm
322         testprog.jpg    Progressive-mode equivalent of testorig.jpg.
323         testimgp.jpg    The output of cjpeg -progressive -optimize testimg.ppm
324 (The first- and second-generation .jpg files aren't identical since JPEG is
325 lossy.)  If you can generate duplicates of the testimg* files then you
326 probably have working programs.
327
328 With most of the makefiles, "make test" will perform the necessary
329 comparisons.
330
331 If you're using a makefile that doesn't provide the test option, run djpeg
332 and cjpeg by hand and compare the output files to testimg* with whatever
333 binary file comparison tool you have.  The files should be bit-for-bit
334 identical.
335
336 If the programs complain "MAX_ALLOC_CHUNK is wrong, please fix", then you
337 need to reduce MAX_ALLOC_CHUNK to a value that fits in type size_t.
338 Try adding "#define MAX_ALLOC_CHUNK 65520L" to jconfig.h.  A less likely
339 configuration error is "ALIGN_TYPE is wrong, please fix": defining ALIGN_TYPE
340 as long should take care of that one.
341
342 If the cjpeg test run fails with "Missing Huffman code table entry", it's a
343 good bet that you needed to define RIGHT_SHIFT_IS_UNSIGNED.  Go back to the
344 configuration step and run ckconfig.c.  (This is a good plan for any other
345 test failure, too.)
346
347 If you are using Unix (one-file) command line style on a non-Unix system,
348 it's a good idea to check that binary I/O through stdin/stdout actually
349 works.  You should get the same results from "djpeg <testorig.jpg >out.ppm"
350 as from "djpeg -outfile out.ppm testorig.jpg".  Note that the makefiles all
351 use the latter style and therefore do not exercise stdin/stdout!  If this
352 check fails, try recompiling with USE_SETMODE or USE_FDOPEN defined.
353 If it still doesn't work, better use two-file style.
354
355 If you chose a memory manager other than jmemnobs.c, you should test that
356 temporary-file usage works.  Try "djpeg -bmp -colors 256 -max 0 testorig.jpg"
357 and make sure its output matches testimg.bmp.  If you have any really large
358 images handy, try compressing them with -optimize and/or decompressing with
359 -colors 256 to make sure your DEFAULT_MAX_MEM setting is not too large.
360
361 NOTE: this is far from an exhaustive test of the JPEG software; some modules,
362 such as 1-pass color quantization, are not exercised at all.  It's just a
363 quick test to give you some confidence that you haven't missed something
364 major.
365
366
367 INSTALLING THE SOFTWARE
368 =======================
369
370 Once you're done with the above steps, you can install the software by
371 copying the executable files (cjpeg, djpeg, jpegtran, rdjpgcom, and wrjpgcom)
372 to wherever you normally install programs.  On Unix systems, you'll also want
373 to put the man pages (cjpeg.1, djpeg.1, jpegtran.1, rdjpgcom.1, wrjpgcom.1)
374 in the man-page directory.  The pre-fab makefiles don't support this step
375 since there's such a wide variety of installation procedures on different
376 systems.
377
378 If you generated a Makefile with the "configure" script, you can just say
379         make install
380 to install the programs and their man pages into the standard places.
381 (You'll probably need to be root to do this.)  We recommend first saying
382         make -n install
383 to see where configure thought the files should go.  You may need to edit
384 the Makefile, particularly if your system's conventions for man page
385 filenames don't match what configure expects.
386
387 If you want to install the IJG library itself, for use in compiling other
388 programs besides ours, then you need to put the four include files
389         jpeglib.h jerror.h jconfig.h jmorecfg.h
390 into your include-file directory, and put the library file libjpeg.a
391 (extension may vary depending on system) wherever library files go.
392 If you generated a Makefile with "configure", it will do what it thinks
393 is the right thing if you say
394         make install-lib
395
396
397 OPTIONAL STUFF
398 ==============
399
400 Progress monitor:
401
402 If you like, you can #define PROGRESS_REPORT (in jconfig.h) to enable display
403 of percent-done progress reports.  The routine provided in cdjpeg.c merely
404 prints percentages to stderr, but you can customize it to do something
405 fancier.
406
407 Utah RLE file format support:
408
409 We distribute the software with support for RLE image files (Utah Raster
410 Toolkit format) disabled, because the RLE support won't compile without the
411 Utah library.  If you have URT version 3.1 or later, you can enable RLE
412 support as follows:
413         1.  #define RLE_SUPPORTED in jconfig.h.
414         2.  Add a -I option to CFLAGS in the Makefile for the directory
415             containing the URT .h files (typically the "include"
416             subdirectory of the URT distribution).
417         3.  Add -L... -lrle to LDLIBS in the Makefile, where ... specifies
418             the directory containing the URT "librle.a" file (typically the
419             "lib" subdirectory of the URT distribution).
420
421 Support for 12-bit-deep pixel data:
422
423 The JPEG standard allows either 8-bit or 12-bit data precision.  (For color,
424 this means 8 or 12 bits per channel, of course.)  If you need to work with
425 deeper than 8-bit data, you can compile the IJG code for 12-bit operation.
426 To do so:
427   1. In jmorecfg.h, define BITS_IN_JSAMPLE as 12 rather than 8.
428   2. In jconfig.h, undefine BMP_SUPPORTED, RLE_SUPPORTED, and TARGA_SUPPORTED,
429      because the code for those formats doesn't handle 12-bit data and won't
430      even compile.  (The PPM code does work, as explained below.  The GIF
431      code works too; it scales 8-bit GIF data to and from 12-bit depth
432      automatically.)
433   3. Compile.  Don't expect "make test" to pass, since the supplied test
434      files are for 8-bit data.
435
436 Currently, 12-bit support does not work on 16-bit-int machines.
437
438 Note that a 12-bit version will not read 8-bit JPEG files, nor vice versa;
439 so you'll want to keep around a regular 8-bit compilation as well.
440 (Run-time selection of data depth, to allow a single copy that does both,
441 is possible but would probably slow things down considerably; it's very low
442 on our to-do list.)
443
444 The PPM reader (rdppm.c) can read 12-bit data from either text-format or
445 binary-format PPM and PGM files.  Binary-format PPM/PGM files which have a
446 maxval greater than 255 are assumed to use 2 bytes per sample, MSB first
447 (big-endian order).  As of early 1995, 2-byte binary format is not
448 officially supported by the PBMPLUS library, but it is expected that a
449 future release of PBMPLUS will support it.  Note that the PPM reader will
450 read files of any maxval regardless of the BITS_IN_JSAMPLE setting; incoming
451 data is automatically rescaled to either maxval=255 or maxval=4095 as
452 appropriate for the cjpeg bit depth.
453
454 The PPM writer (wrppm.c) will normally write 2-byte binary PPM or PGM
455 format, maxval 4095, when compiled with BITS_IN_JSAMPLE=12.  Since this
456 format is not yet widely supported, you can disable it by compiling wrppm.c
457 with PPM_NORAWWORD defined; then the data is scaled down to 8 bits to make a
458 standard 1-byte/sample PPM or PGM file.  (Yes, this means still another copy
459 of djpeg to keep around.  But hopefully you won't need it for very long.
460 Poskanzer's supposed to get that new PBMPLUS release out Real Soon Now.)
461
462 Of course, if you are working with 12-bit data, you probably have it stored
463 in some other, nonstandard format.  In that case you'll probably want to
464 write your own I/O modules to read and write your format.
465
466 Note that a 12-bit version of cjpeg always runs in "-optimize" mode, in
467 order to generate valid Huffman tables.  This is necessary because our
468 default Huffman tables only cover 8-bit data.
469
470 Removing code:
471
472 If you need to make a smaller version of the JPEG software, some optional
473 functions can be removed at compile time.  See the xxx_SUPPORTED #defines in
474 jconfig.h and jmorecfg.h.  If at all possible, we recommend that you leave in
475 decoder support for all valid JPEG files, to ensure that you can read anyone's
476 output.  Taking out support for image file formats that you don't use is the
477 most painless way to make the programs smaller.  Another possibility is to
478 remove some of the DCT methods: in particular, the "IFAST" method may not be
479 enough faster than the others to be worth keeping on your machine.  (If you
480 do remove ISLOW or IFAST, be sure to redefine JDCT_DEFAULT or JDCT_FASTEST
481 to a supported method, by adding a #define in jconfig.h.)
482
483
484 OPTIMIZATION
485 ============
486
487 Unless you own a Cray, you'll probably be interested in making the JPEG
488 software go as fast as possible.  This section covers some machine-dependent
489 optimizations you may want to try.  We suggest that before trying any of
490 this, you first get the basic installation to pass the self-test step.
491 Repeat the self-test after any optimization to make sure that you haven't
492 broken anything.
493
494 The integer DCT routines perform a lot of multiplications.  These
495 multiplications must yield 32-bit results, but none of their input values
496 are more than 16 bits wide.  On many machines, notably the 680x0 and 80x86
497 CPUs, a 16x16=>32 bit multiply instruction is faster than a full 32x32=>32
498 bit multiply.  Unfortunately there is no portable way to specify such a
499 multiplication in C, but some compilers can generate one when you use the
500 right combination of casts.  See the MULTIPLYxxx macro definitions in
501 jdct.h.  If your compiler makes "int" be 32 bits and "short" be 16 bits,
502 defining SHORTxSHORT_32 is fairly likely to work.  When experimenting with
503 alternate definitions, be sure to test not only whether the code still works
504 (use the self-test), but also whether it is actually faster --- on some
505 compilers, alternate definitions may compute the right answer, yet be slower
506 than the default.  Timing cjpeg on a large PGM (grayscale) input file is the
507 best way to check this, as the DCT will be the largest fraction of the runtime
508 in that mode.  (Note: some of the distributed compiler-specific jconfig files
509 already contain #define switches to select appropriate MULTIPLYxxx
510 definitions.)
511
512 If your machine has sufficiently fast floating point hardware, you may find
513 that the float DCT method is faster than the integer DCT methods, even
514 after tweaking the integer multiply macros.  In that case you may want to
515 make the float DCT be the default method.  (The only objection to this is
516 that float DCT results may vary slightly across machines.)  To do that, add
517 "#define JDCT_DEFAULT JDCT_FLOAT" to jconfig.h.  Even if you don't change
518 the default, you should redefine JDCT_FASTEST, which is the method selected
519 by djpeg's -fast switch.  Don't forget to update the documentation files
520 (usage.txt and/or cjpeg.1, djpeg.1) to agree with what you've done.
521
522 If access to "short" arrays is slow on your machine, it may be a win to
523 define type JCOEF as int rather than short.  This will cost a good deal of
524 memory though, particularly in some multi-pass modes, so don't do it unless
525 you have memory to burn and short is REALLY slow.
526
527 If your compiler can compile function calls in-line, make sure the INLINE
528 macro in jmorecfg.h is defined as the keyword that marks a function
529 inline-able.  Some compilers have a switch that tells the compiler to inline
530 any function it thinks is profitable (e.g., -finline-functions for gcc).
531 Enabling such a switch is likely to make the compiled code bigger but faster.
532
533 In general, it's worth trying the maximum optimization level of your compiler,
534 and experimenting with any optional optimizations such as loop unrolling.
535 (Unfortunately, far too many compilers have optimizer bugs ... be prepared to
536 back off if the code fails self-test.)  If you do any experimentation along
537 these lines, please report the optimal settings to jpeg-info@uc.ag so we
538 can mention them in future releases.  Be sure to specify your machine
539 and compiler version.
540
541
542 HINTS FOR SPECIFIC SYSTEMS
543 ==========================
544
545 We welcome reports on changes needed for systems not mentioned here.  Submit
546 'em to jpeg-info@uc.ag.  Also, if configure or ckconfig.c is wrong about how
547 to configure the JPEG software for your system, please let us know.
548
549
550 Acorn RISC OS:
551
552 (Thanks to Simon Middleton for these hints on compiling with Desktop C.)
553 After renaming the files according to Acorn conventions, take a copy of
554 makefile.ansi, change all occurrences of 'libjpeg.a' to 'libjpeg.o' and
555 change these definitions as indicated:
556
557 CFLAGS= -throwback -IC: -Wn
558 LDLIBS=C:o.Stubs
559 SYSDEPMEM=jmemansi.o
560 LN=Link
561 AR=LibFile -c -o
562
563 Also add a new line '.c.o:; $(cc) $< $(cflags) -c -o $@'.  Remove the
564 lines '$(RM) libjpeg.o' and '$(AR2) libjpeg.o' and the 'jconfig.h'
565 dependency section.
566
567 Copy jconfig.txt to jconfig.h.  Edit jconfig.h to define TWO_FILE_COMMANDLINE
568 and CHAR_IS_UNSIGNED.
569
570 Run the makefile using !AMU not !Make.  If you want to use the 'clean' and
571 'test' makefile entries then you will have to fiddle with the syntax a bit
572 and rename the test files.
573
574
575 Amiga:
576
577 SAS C 6.50 reportedly is too buggy to compile the IJG code properly.
578 A patch to update to 6.51 is available from SAS or AmiNet FTP sites.
579
580 The supplied config files are set up to use jmemname.c as the memory
581 manager, with temporary files being created on the device named by
582 "JPEGTMP:".
583
584
585 Atari ST/STE/TT:
586
587 Copy the project files makcjpeg.st, makdjpeg.st, maktjpeg.st, and makljpeg.st
588 to cjpeg.prj, djpeg.prj, jpegtran.prj, and libjpeg.prj respectively.  The
589 project files should work as-is with Pure C.  For Turbo C, change library
590 filenames "pc..." to "tc..." in each project file.  Note that libjpeg.prj
591 selects jmemansi.c as the recommended memory manager.  You'll probably want to
592 adjust the DEFAULT_MAX_MEM setting --- you want it to be a couple hundred K
593 less than your normal free memory.  Put "#define DEFAULT_MAX_MEM nnnn" into
594 jconfig.h to do this.
595
596 To use the 68881/68882 coprocessor for the floating point DCT, add the
597 compiler option "-8" to the project files and replace pcfltlib.lib with
598 pc881lib.lib in cjpeg.prj and djpeg.prj.  Or if you don't have a
599 coprocessor, you may prefer to remove the float DCT code by undefining
600 DCT_FLOAT_SUPPORTED in jmorecfg.h (since without a coprocessor, the float
601 code will be too slow to be useful).  In that case, you can delete
602 pcfltlib.lib from the project files.
603
604 Note that you must make libjpeg.lib before making cjpeg.ttp, djpeg.ttp,
605 or jpegtran.ttp.  You'll have to perform the self-test by hand.
606
607 We haven't bothered to include project files for rdjpgcom and wrjpgcom.
608 Those source files should just be compiled by themselves; they don't
609 depend on the JPEG library.  You can use the default.prj project file
610 of the Pure C distribution to make the programs.
611
612 There is a bug in some older versions of the Turbo C library which causes the
613 space used by temporary files created with "tmpfile()" not to be freed after
614 an abnormal program exit.  If you check your disk afterwards, you will find
615 cluster chains that are allocated but not used by a file.  This should not
616 happen in cjpeg/djpeg/jpegtran, since we enable a signal catcher to explicitly
617 close temp files before exiting.  But if you use the JPEG library with your
618 own code, be sure to supply a signal catcher, or else use a different
619 system-dependent memory manager.
620
621
622 Cray:
623
624 Should you be so fortunate as to be running JPEG on a Cray YMP, there is a
625 compiler bug in old versions of Cray's Standard C (prior to 3.1).  If you
626 still have an old compiler, you'll need to insert a line reading
627 "#pragma novector" just before the loop 
628     for (i = 1; i <= (int) htbl->bits[l]; i++)
629       huffsize[p++] = (char) l;
630 in fix_huff_tbl (in V5beta1, line 204 of jchuff.c and line 176 of jdhuff.c).
631 [This bug may or may not still occur with the current IJG code, but it's
632 probably a dead issue anyway...]
633
634
635 HP-UX:
636
637 If you have HP-UX 7.05 or later with the "software development" C compiler,
638 you should run the compiler in ANSI mode.  If using the configure script,
639 say
640         ./configure CC='cc -Aa'
641 (or -Ae if you prefer).  If configuring by hand, use makefile.ansi and add
642 "-Aa" to the CFLAGS line in the makefile.
643
644 If you have a pre-7.05 system, or if you are using the non-ANSI C compiler
645 delivered with a minimum HP-UX system, then you must use makefile.unix
646 (and do NOT add -Aa); or just run configure without the CC option.
647
648 On HP 9000 series 800 machines, the HP C compiler is buggy in revisions prior
649 to A.08.07.  If you get complaints about "not a typedef name", you'll have to
650 use makefile.unix, or run configure without the CC option.
651
652
653 Macintosh, generic comments:
654
655 The supplied user-interface files (cjpeg.c, djpeg.c, etc) are set up to
656 provide a Unix-style command line interface.  You can use this interface on
657 the Mac by means of the ccommand() library routine provided by Metrowerks
658 CodeWarrior or Think C.  This is only appropriate for testing the library,
659 however; to make a user-friendly equivalent of cjpeg/djpeg you'd really want
660 to develop a Mac-style user interface.  There isn't a complete example
661 available at the moment, but there are some helpful starting points:
662 1. Sam Bushell's free "To JPEG" applet provides drag-and-drop conversion to
663 JPEG under System 7 and later.  This only illustrates how to use the
664 compression half of the library, but it does a very nice job of that part.
665 The CodeWarrior source code is available from http://www.pobox.com/~jsam.
666 2. Jim Brunner prepared a Mac-style user interface for both compression and
667 decompression.  Unfortunately, it hasn't been updated since IJG v4, and
668 the library's API has changed considerably since then.  Still it may be of
669 some help, particularly as a guide to compiling the IJG code under Think C.
670 Jim's code is available from the Info-Mac archives, at sumex-aim.stanford.edu
671 or mirrors thereof; see file /info-mac/dev/src/jpeg-convert-c.hqx.
672
673 jmemmac.c is the recommended memory manager back end for Macintosh.  It uses
674 NewPtr/DisposePtr instead of malloc/free, and has a Mac-specific
675 implementation of jpeg_mem_available().  It also creates temporary files that
676 follow Mac conventions.  (That part of the code relies on System-7-or-later OS
677 functions.  See the comments in jmemmac.c if you need to run it on System 6.)
678 NOTE that USE_MAC_MEMMGR must be defined in jconfig.h to use jmemmac.c.
679
680 You can also use jmemnobs.c, if you don't care about handling images larger
681 than available memory.  If you use any memory manager back end other than
682 jmemmac.c, we recommend replacing "malloc" and "free" by "NewPtr" and
683 "DisposePtr", because Mac C libraries often have peculiar implementations of
684 malloc/free.  (For instance, free() may not return the freed space to the
685 Mac Memory Manager.  This is undesirable for the IJG code because jmemmgr.c
686 already clumps space requests.)
687
688
689 Macintosh, Metrowerks CodeWarrior:
690
691 The Unix-command-line-style interface can be used by defining USE_CCOMMAND.
692 You'll also need to define TWO_FILE_COMMANDLINE to avoid stdin/stdout.
693 This means that when using the cjpeg/djpeg programs, you'll have to type the
694 input and output file names in the "Arguments" text-edit box, rather than
695 using the file radio buttons.  (Perhaps USE_FDOPEN or USE_SETMODE would
696 eliminate the problem, but I haven't heard from anyone who's tried it.)
697
698 On 680x0 Macs, Metrowerks defines type "double" as a 10-byte IEEE extended
699 float.  jmemmgr.c won't like this: it wants sizeof(ALIGN_TYPE) to be a power
700 of 2.  Add "#define ALIGN_TYPE long" to jconfig.h to eliminate the complaint.
701
702 The supplied configuration file jconfig.mac can be used for your jconfig.h;
703 it includes all the recommended symbol definitions.  If you have AppleScript
704 installed, you can run the supplied script makeproj.mac to create CodeWarrior
705 project files for the library and the testbed applications, then build the
706 library and applications.  (Thanks to Dan Sears and Don Agro for this nifty
707 hack, which saves us from trying to maintain CodeWarrior project files as part
708 of the IJG distribution...)
709
710
711 Macintosh, Think C:
712
713 The documentation in Jim Brunner's "JPEG Convert" source code (see above)
714 includes detailed build instructions for Think C; it's probably somewhat
715 out of date for the current release, but may be helpful.
716
717 If you want to build the minimal command line version, proceed as follows.
718 You'll have to prepare project files for the programs; we don't include any
719 in the distribution since they are not text files.  Use the file lists in
720 any of the supplied makefiles as a guide.  Also add the ANSI and Unix C
721 libraries in a separate segment.  You may need to divide the JPEG files into
722 more than one segment; we recommend dividing compression and decompression
723 modules.  Define USE_CCOMMAND in jconfig.h so that the ccommand() routine is
724 called.  You must also define TWO_FILE_COMMANDLINE because stdin/stdout
725 don't handle binary data correctly.
726
727 On 680x0 Macs, Think C defines type "double" as a 12-byte IEEE extended float.
728 jmemmgr.c won't like this: it wants sizeof(ALIGN_TYPE) to be a power of 2.
729 Add "#define ALIGN_TYPE long" to jconfig.h to eliminate the complaint.
730
731 jconfig.mac should work as a jconfig.h configuration file for Think C,
732 but the makeproj.mac AppleScript script is specific to CodeWarrior.  Sorry.
733
734
735 MIPS R3000:
736
737 MIPS's cc version 1.31 has a rather nasty optimization bug.  Don't use -O
738 if you have that compiler version.  (Use "cc -V" to check the version.)
739 Note that the R3000 chip is found in workstations from DEC and others.
740
741
742 MS-DOS, generic comments for 16-bit compilers:
743
744 The IJG code is designed to work well in 80x86 "small" or "medium" memory
745 models (i.e., data pointers are 16 bits unless explicitly declared "far";
746 code pointers can be either size).  You may be able to use small model to
747 compile cjpeg or djpeg by itself, but you will probably have to use medium
748 model for any larger application.  This won't make much difference in
749 performance.  You *will* take a noticeable performance hit if you use a
750 large-data memory model, and you should avoid "huge" model if at all
751 possible.  Be sure that NEED_FAR_POINTERS is defined in jconfig.h if you use
752 a small-data memory model; be sure it is NOT defined if you use a large-data
753 model.  (The supplied makefiles and jconfig files for Borland and Microsoft C
754 compile in medium model and define NEED_FAR_POINTERS.)
755
756 The DOS-specific memory manager, jmemdos.c, should be used if possible.
757 It needs some assembly-code routines which are in jmemdosa.asm; make sure
758 your makefile assembles that file and includes it in the library.  If you
759 don't have a suitable assembler, you can get pre-assembled object files for
760 jmemdosa by FTP from ftp.uu.net:/graphics/jpeg/jdosaobj.zip.  (DOS-oriented
761 distributions of the IJG source code often include these object files.)
762
763 When using jmemdos.c, jconfig.h must define USE_MSDOS_MEMMGR and must set
764 MAX_ALLOC_CHUNK to less than 64K (65520L is a typical value).  If your
765 C library's far-heap malloc() can't allocate blocks that large, reduce
766 MAX_ALLOC_CHUNK to whatever it can handle.
767
768 If you can't use jmemdos.c for some reason --- for example, because you
769 don't have an assembler to assemble jmemdosa.asm --- you'll have to fall
770 back to jmemansi.c or jmemname.c.  You'll probably still need to set
771 MAX_ALLOC_CHUNK in jconfig.h, because most DOS C libraries won't malloc()
772 more than 64K at a time.  IMPORTANT: if you use jmemansi.c or jmemname.c,
773 you will have to compile in a large-data memory model in order to get the
774 right stdio library.  Too bad.
775
776 wrjpgcom needs to be compiled in large model, because it malloc()s a 64KB
777 work area to hold the comment text.  If your C library's malloc can't
778 handle that, reduce MAX_COM_LENGTH as necessary in wrjpgcom.c.
779
780 Most MS-DOS compilers treat stdin/stdout as text files, so you must use
781 two-file command line style.  But if your compiler has either fdopen() or
782 setmode(), you can use one-file style if you like.  To do this, define
783 USE_SETMODE or USE_FDOPEN so that stdin/stdout will be set to binary mode.
784 (USE_SETMODE seems to work with more DOS compilers than USE_FDOPEN.)  You
785 should test that I/O through stdin/stdout produces the same results as I/O
786 to explicitly named files... the "make test" procedures in the supplied
787 makefiles do NOT use stdin/stdout.
788
789
790 MS-DOS, generic comments for 32-bit compilers:
791
792 None of the above comments about memory models apply if you are using a
793 32-bit flat-memory-space environment, such as DJGPP or Watcom C.  (And you
794 should use one if you have it, as performance will be much better than
795 8086-compatible code!)  For flat-memory-space compilers, do NOT define
796 NEED_FAR_POINTERS, and do NOT use jmemdos.c.  Use jmemnobs.c if the
797 environment supplies adequate virtual memory, otherwise use jmemansi.c or
798 jmemname.c.
799
800 You'll still need to be careful about binary I/O through stdin/stdout.
801 See the last paragraph of the previous section.
802
803
804 MS-DOS, Borland C:
805
806 Be sure to convert all the source files to DOS text format (CR/LF newlines).
807 Although Borland C will often work OK with unmodified Unix (LF newlines)
808 source files, sometimes it will give bogus compile errors.
809 "Illegal character '#'" is the most common such error.  (This is true with
810 Borland C 3.1, but perhaps is fixed in newer releases.)
811
812 If you want one-file command line style, just undefine TWO_FILE_COMMANDLINE.
813 jconfig.bcc already includes #define USE_SETMODE to make this work.
814 (fdopen does not work correctly.)
815
816
817 MS-DOS, Microsoft C:
818
819 makefile.mc6 works with Microsoft C, DOS Visual C++, etc.  It should only
820 be used if you want to build a 16-bit (small or medium memory model) program.
821
822 If you want one-file command line style, just undefine TWO_FILE_COMMANDLINE.
823 jconfig.mc6 already includes #define USE_SETMODE to make this work.
824 (fdopen does not work correctly.)
825
826 Note that this makefile assumes that the working copy of itself is called
827 "makefile".  If you want to call it something else, say "makefile.mak",
828 be sure to adjust the dependency line that reads "$(RFILE) : makefile".
829 Otherwise the make will fail because it doesn't know how to create "makefile".
830 Worse, some releases of Microsoft's make utilities give an incorrect error
831 message in this situation.
832
833 Old versions of MS C fail with an "out of macro expansion space" error
834 because they can't cope with the macro TRACEMS8 (defined in jerror.h).
835 If this happens to you, the easiest solution is to change TRACEMS8 to
836 expand to nothing.  You'll lose the ability to dump out JPEG coefficient
837 tables with djpeg -debug -debug, but at least you can compile.
838
839 Original MS C 6.0 is very buggy; it compiles incorrect code unless you turn
840 off optimization entirely (remove -O from CFLAGS).  6.00A is better, but it
841 still generates bad code if you enable loop optimizations (-Ol or -Ox).
842
843 MS C 8.0 crashes when compiling jquant1.c with optimization switch /Oo ...
844 which is on by default.  To work around this bug, compile that one file
845 with /Oo-.
846
847
848 Microsoft Windows (all versions), generic comments:
849
850 Some Windows system include files define typedef boolean as "unsigned char".
851 The IJG code also defines typedef boolean, but we make it "int" by default.
852 This doesn't affect the IJG programs because we don't import those Windows
853 include files.  But if you use the JPEG library in your own program, and some
854 of your program's files import one definition of boolean while some import the
855 other, you can get all sorts of mysterious problems.  A good preventive step
856 is to make the IJG library use "unsigned char" for boolean.  To do that,
857 add something like this to your jconfig.h file:
858         /* Define "boolean" as unsigned char, not int, per Windows custom */
859         #ifndef __RPCNDR_H__    /* don't conflict if rpcndr.h already read */
860         typedef unsigned char boolean;
861         #endif
862         #define HAVE_BOOLEAN    /* prevent jmorecfg.h from redefining it */
863 (This is already in jconfig.vc, by the way.)
864
865 windef.h contains the declarations
866         #define far
867         #define FAR far
868 Since jmorecfg.h tries to define FAR as empty, you may get a compiler
869 warning if you include both jpeglib.h and windef.h (which windows.h
870 includes).  To suppress the warning, you can put "#ifndef FAR"/"#endif"
871 around the line "#define FAR" in jmorecfg.h.
872 (Something like this is already in jmorecfg.h, by the way.)
873
874 When using the library in a Windows application, you will almost certainly
875 want to modify or replace the error handler module jerror.c, since our
876 default error handler does a couple of inappropriate things:
877   1. it tries to write error and warning messages on stderr;
878   2. in event of a fatal error, it exits by calling exit().
879
880 A simple stopgap solution for problem 1 is to replace the line
881         fprintf(stderr, "%s\n", buffer);
882 (in output_message in jerror.c) with
883         MessageBox(GetActiveWindow(),buffer,"JPEG Error",MB_OK|MB_ICONERROR);
884 It's highly recommended that you at least do that much, since otherwise
885 error messages will disappear into nowhere.  (Beginning with IJG v6b, this
886 code is already present in jerror.c; just define USE_WINDOWS_MESSAGEBOX in
887 jconfig.h to enable it.)
888
889 The proper solution for problem 2 is to return control to your calling
890 application after a library error.  This can be done with the setjmp/longjmp
891 technique discussed in libjpeg.txt and illustrated in example.c.  (NOTE:
892 some older Windows C compilers provide versions of setjmp/longjmp that
893 don't actually work under Windows.  You may need to use the Windows system
894 functions Catch and Throw instead.)
895
896 The recommended memory manager under Windows is jmemnobs.c; in other words,
897 let Windows do any virtual memory management needed.  You should NOT use
898 jmemdos.c nor jmemdosa.asm under Windows.
899
900 For Windows 3.1, we recommend compiling in medium or large memory model;
901 for newer Windows versions, use a 32-bit flat memory model.  (See the MS-DOS
902 sections above for more info about memory models.)  In the 16-bit memory
903 models only, you'll need to put
904         #define MAX_ALLOC_CHUNK 65520L  /* Maximum request to malloc() */
905 into jconfig.h to limit allocation chunks to 64Kb.  (Without that, you'd
906 have to use huge memory model, which slows things down unnecessarily.)
907 jmemnobs.c works without modification in large or flat memory models, but to
908 use medium model, you need to modify its jpeg_get_large and jpeg_free_large
909 routines to allocate far memory.  In any case, you might like to replace
910 its calls to malloc and free with direct calls on Windows memory allocation
911 functions.
912
913 You may also want to modify jdatasrc.c and jdatadst.c to use Windows file
914 operations rather than fread/fwrite.  This is only necessary if your C
915 compiler doesn't provide a competent implementation of C stdio functions.
916
917 You might want to tweak the RGB_xxx macros in jmorecfg.h so that the library
918 will accept or deliver color pixels in BGR sample order, not RGB; BGR order
919 is usually more convenient under Windows.  Note that this change will break
920 the sample applications cjpeg/djpeg, but the library itself works fine.
921
922
923 Many people want to convert the IJG library into a DLL.  This is reasonably
924 straightforward, but watch out for the following:
925
926   1. Don't try to compile as a DLL in small or medium memory model; use
927 large model, or even better, 32-bit flat model.  Many places in the IJG code
928 assume the address of a local variable is an ordinary (not FAR) pointer;
929 that isn't true in a medium-model DLL.
930
931   2. Microsoft C cannot pass file pointers between applications and DLLs.
932 (See Microsoft Knowledge Base, PSS ID Number Q50336.)  So jdatasrc.c and
933 jdatadst.c don't work if you open a file in your application and then pass
934 the pointer to the DLL.  One workaround is to make jdatasrc.c/jdatadst.c
935 part of your main application rather than part of the DLL.
936
937   3. You'll probably need to modify the macros GLOBAL() and EXTERN() to
938 attach suitable linkage keywords to the exported routine names.  Similarly,
939 you'll want to modify METHODDEF() and JMETHOD() to ensure function pointers
940 are declared in a way that lets application routines be called back through
941 the function pointers.  These macros are in jmorecfg.h.  Typical definitions
942 for a 16-bit DLL are:
943         #define GLOBAL(type)            type _far _pascal _loadds _export
944         #define EXTERN(type)            extern type _far _pascal _loadds
945         #define METHODDEF(type)         static type _far _pascal
946         #define JMETHOD(type,methodname,arglist)  \
947                 type (_far _pascal *methodname) arglist
948 For a 32-bit DLL you may want something like
949         #define GLOBAL(type)            __declspec(dllexport) type
950         #define EXTERN(type)            extern __declspec(dllexport) type
951 Although not all the GLOBAL routines are actually intended to be called by
952 the application, the performance cost of making them all DLL entry points is
953 negligible.
954
955 The unmodified IJG library presents a very C-specific application interface,
956 so the resulting DLL is only usable from C or C++ applications.  There has
957 been some talk of writing wrapper code that would present a simpler interface
958 usable from other languages, such as Visual Basic.  This is on our to-do list
959 but hasn't been very high priority --- any volunteers out there?
960
961
962 Microsoft Windows, Borland C:
963
964 The provided jconfig.bcc should work OK in a 32-bit Windows environment,
965 but you'll need to tweak it in a 16-bit environment (you'd need to define
966 NEED_FAR_POINTERS and MAX_ALLOC_CHUNK).  Beware that makefile.bcc will need
967 alteration if you want to use it for Windows --- in particular, you should
968 use jmemnobs.c not jmemdos.c under Windows.
969
970 Borland C++ 4.5 fails with an internal compiler error when trying to compile
971 jdmerge.c in 32-bit mode.  If enough people complain, perhaps Borland will fix
972 it.  In the meantime, the simplest known workaround is to add a redundant
973 definition of the variable range_limit in h2v1_merged_upsample(), at the head
974 of the block that handles odd image width (about line 268 in v6 jdmerge.c):
975   /* If image width is odd, do the last output column separately */
976   if (cinfo->output_width & 1) {
977     register JSAMPLE * range_limit = cinfo->sample_range_limit; /* ADD THIS */
978     cb = GETJSAMPLE(*inptr1);
979 Pretty bizarre, especially since the very similar routine h2v2_merged_upsample
980 doesn't trigger the bug.
981 Recent reports suggest that this bug does not occur with "bcc32a" (the
982 Pentium-optimized version of the compiler).
983
984 Another report from a user of Borland C 4.5 was that incorrect code (leading
985 to a color shift in processed images) was produced if any of the following
986 optimization switch combinations were used: 
987         -Ot -Og
988         -Ot -Op
989         -Ot -Om
990 So try backing off on optimization if you see such a problem.  (Are there
991 several different releases all numbered "4.5"??)
992
993
994 Microsoft Windows, Microsoft Visual C++:
995
996 jconfig.vc should work OK with any Microsoft compiler for a 32-bit memory
997 model.  makefile.vc is intended for command-line use.  (If you are using
998 the Developer Studio environment, you may prefer the DevStudio project
999 files; see below.)
1000
1001 IJG JPEG 7 adds extern "C" to jpeglib.h.  This avoids the need to put
1002 extern "C" { ... } around #include "jpeglib.h" in your C++ application.
1003 You can also force VC++ to treat the library as C++ code by renaming
1004 all the *.c files to *.cpp (and adjusting the makefile to match).
1005 In this case you also need to define the symbol DONT_USE_EXTERN_C in
1006 the configuration to prevent jpeglib.h from using extern "C".
1007
1008
1009 Microsoft Windows, Microsoft Visual C++ 6 Developer Studio:
1010
1011 We include makefiles that should work as project files in DevStudio 6.0 or
1012 later.  There is a library makefile that builds the IJG library as a static
1013 Win32 library, and application makefiles that build the sample applications
1014 as Win32 console applications.  (Even if you only want the library, we
1015 recommend building the applications so that you can run the self-test.)
1016
1017 To use:
1018 1. Open the command prompt, change to the main directory and execute the
1019    command line
1020         NMAKE /f makefile.vc  setup-vc6
1021    This will move jconfig.vc to jconfig.h and makefiles to project files.
1022    (Note that the renaming is critical!)
1023 2. Open the workspace file jpeg.dsw, build the library project.
1024    (If you are using DevStudio more recent than 6.0, you'll probably
1025    get a message saying that the project files are being updated.)
1026 3. Open the workspace file apps.dsw, build the application projects.
1027 4. To perform the self-test, execute the command line
1028         NMAKE /f makefile.vc  test-build
1029 5. Move the application .exe files from `app`\Release to an
1030    appropriate location on your path.
1031
1032
1033 Microsoft Windows, Microsoft Visual C++ 2010 Developer Studio (v10):
1034
1035 We include makefiles that should work as project files in Visual Studio
1036 2010 or later.  There is a library makefile that builds the IJG library
1037 as a static Win32 library, and application makefiles that build the sample
1038 applications as Win32 console applications.  (Even if you only want the
1039 library, we recommend building the applications so that you can run the
1040 self-test.)
1041
1042 To use:
1043 1. Open the command prompt, change to the main directory and execute the
1044    command line
1045         NMAKE /f makefile.vc  setup-v10
1046    This will move jconfig.vc to jconfig.h and makefiles to project files.
1047    (Note that the renaming is critical!)
1048 2. Open the solution file jpeg.sln, build the library project.
1049    (If you are using Visual Studio more recent than 2010 (v10), you'll
1050    probably get a message saying that the project files are being updated.)
1051 3. Open the solution file apps.sln, build the application projects.
1052 4. To perform the self-test, execute the command line
1053         NMAKE /f makefile.vc  test-build
1054 5. Move the application .exe files from `app`\Release to an
1055    appropriate location on your path.
1056
1057 Note:
1058 There seems to be an optimization bug in the compiler which causes the
1059 self-test to fail with the color quantization option.
1060 We have disabled optimization for the file jquant2.c in the library
1061 project file which causes the self-test to pass properly.
1062
1063
1064 OS/2, Borland C++:
1065
1066 Watch out for optimization bugs in older Borland compilers; you may need
1067 to back off the optimization switch settings.  See the comments in
1068 makefile.bcc.
1069
1070
1071 SGI:
1072
1073 On some SGI systems, you may need to set "AR2= ar -ts" in the Makefile.
1074 If you are using configure, you can do this by saying
1075         ./configure RANLIB='ar -ts'
1076 This change is not needed on all SGIs.  Use it only if the make fails at the
1077 stage of linking the completed programs.
1078
1079 On the MIPS R4000 architecture (Indy, etc.), the compiler option "-mips2"
1080 reportedly speeds up the float DCT method substantially, enough to make it
1081 faster than the default int method (but still slower than the fast int
1082 method).  If you use -mips2, you may want to alter the default DCT method to
1083 be float.  To do this, put "#define JDCT_DEFAULT JDCT_FLOAT" in jconfig.h.
1084
1085
1086 VMS:
1087
1088 On an Alpha/VMS system with MMS, be sure to use the "/Marco=Alpha=1"
1089 qualifier with MMS when building the JPEG package.
1090
1091 VAX/VMS v5.5-1 may have problems with the test step of the build procedure
1092 reporting differences when it compares the original and test images.  If the
1093 error points to the last block of the files, it is most likely bogus and may
1094 be safely ignored.  It seems to be because the files are Stream_LF and
1095 Backup/Compare has difficulty with the (presumably) null padded files.
1096 This problem was not observed on VAX/VMS v6.1 or AXP/VMS v6.1.