This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: [RFC] jpeg library


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


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