| 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.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. |
| |
| |
| 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're using a makefile that doesn't provide this option, run |
| djpeg and cjpeg 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 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). |
| |
| |
| 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 V3, line 42 of jchuff.c and line 38 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 the setmode() library |
| routine, you can define USE_SETMODE to get one-file style. (Don't forget to |
| change the "make test" script in the Makefile if you do so.) |
| |
| 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. |
| |
| |
| 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. (If you choose two-file style, change the |
| "make test" section of the Makefile accordingly.) 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. |
| |
| |
| 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. |