[RFC] jpeg library
Yaakov (Cygwin/X)
yselkowitz@users.sourceforge.net
Sun Jun 28 07:13:00 GMT 2009
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
More information about the Cygwin
mailing list