Message-ID: <4A46FAA4.2@users.sourceforge.net>
Date: Sun, 28 Jun 2009 00:07:48 -0500
From: "Yaakov (Cygwin/X)" <yselkowitz AT users DOT sourceforge DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [RFC] jpeg library
References: <4A466538 DOT 8030007 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <4A466538.8030007@cwilson.fastmail.fm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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