[RFC] jpeg library
Charles Wilson
cygwin@cwilson.fastmail.fm
Sat Jun 27 22:04:00 GMT 2009
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
More information about the Cygwin
mailing list