For many years -- since the first "net release" after B20.1 in fact -- cygwin's jpeg library has included the so-called "lossless jpeg" patch. This has been somewhat controversial.
The patch modifies certain data structures that are marked "private" in the jpeg headers, but they *are* in the headers. Therefore, many clients have manipulated those structures directly. To interoperate with cygwin's lossless-patched version, they had to make certain accomodations: http://cygwin.com/ml/cygwin/2005-07/msg01005.html So the question becomes, why did we (I) add it in the first place, and why do we still needed it? I added it because I needed it to deal with certain medical imagery, and frankly was unaware at the time that changing "private" data structures would really affect anybody else. Isn't that what "private" means? 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. 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. 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! Well, I see an opportunity to do exactly that: we are soon to release cygwin-1.7, AND upgrade to gcc4/dw2/shared-libgcc as the standard compiler. Acccording to: http://cygwin.com/ml/cygwin-apps/2009-04/msg00034.html this gives us a free pass to break ABI on DLLs -- like jpeg. (Sortof. It's really only a free pass IF the ABI breakage is specifically caused by the switch to cygwin1.7/gcc4/dw2/shared-libgcc. NOT if the ABI breakage is caused by some other internal change...like (reverting) modifications to data structures which are publicly exposed but marked private in header file comments. So, the proposal below is stretching the rules a bit. Which is why I want comments.) So... 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: jpeg 6b-N libjpeg-devel 6b-N libjpeg62 "cygjpeg-62.dll" 6b-N 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. 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. Alternative: 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 b) any applications that dlopen libjpeg would need patching, in perpetuity. I'm not sure this is much of an issue. Open for discussion... -- Chuck -- 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
