Charles Wilson wrote:
> OK...new plan: jpeg-v7 will be released for cygwin-1.7 only, using
> gcc4/dw2/shared-libgcc only, and will have the name "cygjpeg-7.dll". It
> will NOT have lossless jpeg support.
>
> I'll do this soon.
I've just posted, for 1.7 only, an update for libjpeg to jpeg v7. T
Charles Wilson wrote:
> In that same conversation, there is a lot of mention of the use of
> symbol versioning as the panacea for all possible version conflicts.
> Nobody has seemed to point out that it works only on ELF systems.
This will not be a problem for us forever, I hope :)
cheers,
Dave Korn wrote:
> I was just about to say "We could always try and find a security
> vulnerability, that's the only thing that would cause upstream to update
> libjpeg these days! :) But then I took a look at the new change.log and it's
> actually crammed with new and improved functionality, s
he patches from jpegclub.org, so that's good (Hmmm. Actually, the
jpegclub.org website has been updated and now claims
"JPEGclub.org...maintains the Independent JPEG Group's (IJG) software.".
I guess this isn't surprising, as jpegclub.org has always been Guido
Vollbeding'
Yaakov (Cygwin/X) wrote:
> On 28/06/2009 01:17, Charles Wilson wrote:
>> Nope. Upstream development is DEAD. There was some flurry of activity
>> about two years ago, but it never went anywhere. If IJG's libjpeg
>> wasn't so widespread and widely used, I'd want to look at some other
>> library t
On 28/06/2009 01:17, Charles Wilson wrote:
Nope. Upstream development is DEAD. There was some flurry of activity
about two years ago, but it never went anywhere. If IJG's libjpeg
wasn't so widespread and widely used, I'd want to look at some other
library that supports the format...
Actually
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 in
ce 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 wo
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&#x
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
I was trying to build a program which uses libjpeg.
./configure works, but make beaks down.
# The issue is:
program io-jpeg .c tries to access an undefined structure member.
According to: http://cygwin.com/ml/cygwin/2005-07/msg01005.html
This member was deliberately taken out of cygwin's li
11 matches
Mail list logo
