[RFC] jpeg library

[Yaakov (Cygwin/X)]

On 27/06/2009 13:30, Charles Wilson wrote:
> Well, I no longer need to deal with that sort of imagery, and "private"
> never really was very private, and it DID cause lots of people grief.

Moreso, the patch removed the height_in_blocks/width_in_blocks members 
from struct jpeg_component_info, which are used in a transupp.c file 
which is part of several desktop image viewers (I know of at least six), 
as well as the progressive_mode member from the jpeg_compress_struct 
struct, which is used in gtk+-2.12 and up.

> And, our build environment for packages is much nicer now than it was in
> the early days, so any Joe who needs lossless jpeg can easily build it
> themselves.  So, it'd be nice to get rid of the lossless jpeg patch.

+1

> Why shouldn't we get rid of it?  Well, because over the years those
> other clients have added lots of workarounds to accommodate cygwin's
> jpeg library.  If we removed the lossless jpeg stuff, then they wouldn't
> need them -- but until they too removed their workarounds, their builds
> would break on cygwin again!

What is the chance of breakage for regular clients?

> I propose to release a new libjpeg for cygwin-1.7 using gcc4 with the
> shared libgcc runtime, once both cygwin-1.7 and gcc4 are officially
> non-beta (e.g. moved to curr, not test).  This libjpeg will be named:

I presume that an upstream (ABI) version bump -- the easiest time to 
make changes like this -- is not in sight.

> just like the current packages, where N>  20.  The DLL number, name, and
> package name will NOT be incremented.  Existing packages that use
> libjpeg, AND that "illegally" accessed the so-called "private" data
> members, will break and will need to be recompiled, without whatever
> internal workarounds they had previously implemented to deal with our
> lossless stuff.

May I suggest making these available for a limited-time manual download 
for maintainers to test and, if necessary, rebuild their own packages to 
be ready when these are released.

> I could be persuaded to release it earlier.  That is, before cygwin-1.7
> goes live although I'd rather not cause instability in the distro this
> close to cygwin-1.7's release.  Or, sometime after cygwin-1.7.1, but
> before gcc-4.x goes gold.

I think earlier is better, but it should be coordinated.

> Another alternative is to release the lossless-jpeg-less libjpeg now,
> for cygwin-1.7(beta), using gcc-3.4.5, under a new DLL name.  This way,
> there is an ABI breakage but it's in a new DLL with a new number
> (cygjpeg-63? -100? something), so nobody has a problem; doing this won't
> destabilize the cygwin distribution at all.  It's just a normal DLL
> update.  Then, when cygwin1.7 and gcc4 go live, I rebuild the
> cygjpeg-100.dll using the new gcc4 and we have (maybe) a second ABI
> breakage, only this one isn't accompanied by a DLL version bump, because
> it would be due solely to issues related to the compiler switch, per:
>    http://cygwin.com/ml/cygwin-apps/2009-04/msg00034.html
>
> The downside of this approach is cygwin's jpeg DLL would have a
> different name than is normally implied by the stock build machinery, and
>    a) we would continue to have to patch our jpeg builds to use the new
> numbering sequence in perpetuity

Which is one reason I was against gcc4-ABI-bumps in the first place.

>    b) any applications that dlopen libjpeg would need patching, in
> perpetuity. I'm not sure this is much of an issue.

Can't think of any off the top of my head, but it's possible.

> Open for discussion...

My $0.02 CAD.


Yaakov

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple