This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [RFC] jpeg library
On 28/06/2009 01:17, Charles Wilson wrote:
You mean for clients that aren't naughty, and do not/never did access
these "private" fields? None, as far as I can tell. The *size* of the
struct doesn't change. Only the names of some of the fields (not their
type), and their meaning. Some purely internal structs change
significantly, but that shouldn't affect external clients, even naughty
ones.
Although the actual strings associated with various error code numbers
changes, so that could lead to some surprising incorrect error messages
until clients are recompiled.
In any event, if I release a new cygjpeg-62.dll (same as current name)
without the lossless jpeg patch, and it DOES break everything in sight,
well then, I'll withdraw it and we'll go with the plan B transition.
That should be easily verified with a bit of testing on everyone's part,
*before* the release.
Well, "test" release, sure. But given the interlocking dependencies of
libraries (esp. graphics libraries), you'd need an ever-increasing
number of these libraries in pending/test state. I don't have the
bandwidth to manage that outside of the sourceware facilities. Since we
have a perfectly good mirror system and "test status" already available
for such things...
If there is indeed no ABI breakage in the normal case, there shouldn't
be any need for a bunch of packages in testing; everyone just tests the
new libjpeg62, and if their package(s) still work, nothing more to do,
right?
Well, with 1.7 due out sometime in the next week or so, I really don't
want to destabilize that.
That shouldn't stop you from a test: version ASAP.
Yeah, but on the other hand, every distro out there has a stack of
patches for libjpeg, because upstream is dead but the code has bugs.
Thus, debian has a list of libjpeg patches that, for all intents and
purposes, they must now "maintain in perpetuity".
True; thankfully the Linux distros are doing the hard work for us. :-)
But this isn't a "pseudo-incompatibility" caused by a simple switch to
gcc4/shared-libgcc. This is a real ABI violation we're contemplating.
It's exactly what DLL version number bumps are FOR.
Freetype went through a similar transition some time ago[1]: they used
to expose many internal symbols and headers, and before 2.2.0 they
stopped. Interestingly, they didn't change the ABI number, since the
only changes were to things supposed to be internal. Everyone fixed
their packages (and the FT devs did help provide packages), and life
moved on.
[1] http://freetype.sourceforge.net/freetype2/freetype-2.2.0.html
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