This is the mail archive of the
mailing list for the Cygwin project.
Re: error compiling gd-1.8.3 under cygwin-1.1.7
- To: "Dr. Volker Zell" <Dr dot Volker dot Zell at oracle dot com>
- Subject: Re: error compiling gd-1.8.3 under cygwin-1.1.7
- From: "Charles S. Wilson" <cwilson at ece dot gatech dot edu>
- Date: Fri, 02 Feb 2001 02:48:17 -0500
- CC: Thomas Boutell <boutell at vader dot boutell dot com>, cygwin-apps at cygwin dot com
- References: <Pine.LNX.3.95.1010201102210.11386Bfirstname.lastname@example.org> <email@example.com>
"Dr. Volker Zell" wrote:
> I found my mistake. I'm using jpeg-6b but with the lossless jpeg patch applied. Actually this patch
> removes the definition of progressive_mode. :-(
> The lossless jpeg libs and headers are standard now in the cygwin emnvironment.
Hmmm...then your app (gd ?) was probably accessing private fields that
were subject to modification -- as Ken puts it below, "playing with
fire." Progressive mode isn't gone, but how it is handled internally is
before : cinfo->progressive_mode
was a "boolean" (int)
with lj: cinfo->process is a int that takes one
of several values (e.g. JPROC_PROGRESSIVE)
Again, this is all handled *inside* the private area of libjpeg. It
really shouldn't break your program unless your program was doing
naughty things, like messing with internal data structures.
From an exchange on the ijg mailing list last November:
> Charles Wilson said:
> > Perhaps this should be considered a bug in the lossless jpeg stuff, but
> > because of the API renames required for ljpeg, some programs written for
> > regular jpeg can't use the extended library that implements both
> > lossless and regular jpeg.
Ken Murchison replied:
> The renaming of some of the fields was done primarily to make the code
> more readable/understandable in a two codec system. For example
> 'width_in_blocks' make no sense for lossless, because lossless only
> deals with single samples.
> I made an effort to not change the existing external API, and I *think*
> I was successful (I may have hacked something and forgot about it). I
> wasn't too worried about changing the fields in question because I
> believe they were intended to only be used inside the library itself.
> In fact, these fields fall in an area of jpeglib.h which contains the
> following warning:
> /* Remaining fields should be treated as private by applications. */
> If you have an app which is using these fields directly I apologize for
> the inconvenience, but IMHO you were kind of playing with fire. That
> being said, if your level of JPEG expertise is such that you are
> comfortable using these fields, you most likely have the level of
> expertise to solve this problem by either modifying the patch or setting
> up defines in the Makefiles like
> '-Dwidth_in_data_units=width_in_blocks'. I currently don't have the
> time to attack this myself (in fact the project for which I developed
> lossless never happened), but I'd be willing to help provide guidance.
> Kenneth Murchison Oceana Matrix Ltd.
> Software Engineer 21 Princeton Place
> 716-662-8973 x26 Orchard Park, NY 14127
> --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp