This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: error compiling gd-1.8.3 under cygwin-1.1.7

"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.
> Regards,
> Ken
> -- 
> Kenneth Murchison     Oceana Matrix Ltd.
> Software Engineer     21 Princeton Place
> 716-662-8973 x26      Orchard Park, NY 14127
> --PGP Public Key--

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]