Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3BA8E6FC.5020009@ece.gatech.edu>
Date: Wed, 19 Sep 2001 14:42:04 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: Sven =?ISO-8859-1?Q?K=F6hler?= <skoehler AT upb DOT de>
CC: cygwin-apps AT cygwin DOT com
Subject: Re: libjpeg - header file is broken ?
References: <008001c1409c$5f76edb0$2c00a8c0 AT APPZLAP>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Sven Köhler wrote:

 > libgd didn't compile - the progressive_mode in the
 > jpeg_decompress_struct was missing. i downloaded libjpeg and
 > installed that one (which was in fact the same version than that
 > installed by cygwin-setup)

No, it is not.  If you (a) had downloaded the jpeg6b-3-src.tar.gz file 
from sourceware, or (b) read /usr/doc/Cygwin/jpeg-6b.README, you would 
realize that...

 > now libgd does compile ...

the cygwin version has had the lossless jpeg patch applied.  This 
changes some internal data structures inside the jpeg library -- which 
ARE NOT SUPPOSED TO BE ACCESSED BY CLIENT PROGRAMS.

See this thread:

http://www.cygwin.com/ml/cygwin-apps/2001-02/msg00000.html

However, if you *must* access these things, then make these changes in 
your code:

cinfo->progressive_mode ---> (cinfo->process == JPROC_PROGRESSIVE)
cinfo->min_DCT_scaled_size ---> cinfo->min_codec_data_unit
cinfo->coef ---> cinfo->codec
cinfo->blocks_in_MCU ---> cinfo->data_units_in_MCU
D_MAX_BLOCKS_IN_MCU ---> D_MAX_DATA_UNITS_IN_MCU
C_MAX_BLOCKS_IN_MCU ---> C_MAX_DATA_UNITS_IN_MCU
DCTSIZE ---> cinfo->data_unit
MCU_blocks ---> MCU_data_units
DCT_scaled_size ---> codec_data_unit

(There may be others; check the ljpeg patch for details.  This patch is 
included in the sourceware distribution of jpeg-6b-3-src.tar.gz, or can 
be obtained from ftp.simplesystems.org)


The netpbm package 'solved' this problem by doing the following:

------------
/* With the lossless jpeg patch applied to the Jpeg library
(ftp://ftp.wizards.dupont.com/pub/ImageMagick/delegates/ljpeg-6b.tar.gz),
     the name of min_DCT_scaled_size changes to min_codec_data_unit,
     for some reason.  With this macro, we change it back.
*/
#define min_codec_data_unit min_DCT_scaled_size
#include <jpeglib.h>
#undef min_codec_data_unit
-------------

(Out of the jpeg private definitions modified by the lossless patch, 
netpbm only tries to access "min_DCT_scaled_size".  Therefore, netpbm 
only needs to worry about that one, and not any of the others)

--Chuck