[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#717076: tech-ctte: Decide what jpeg library the Debian project will use

On 17/07/13 22:49, Ian Jackson wrote:
> Perhaps we could just patch our libjpeg6b to have the necessary
> function.  It sounds like an API deficiency that it's missing.

It appears that libjpeg-turbo 1.3+ has a libjpeg8-compatible
jpeg_mem_(src|dest) by default, even if it's told to implement a
libjpeg6b-compatible ABI. That would be fine for ioquake3 (and basically
equivalent to the embedded code copy used before it upgraded to version
8). A strictly libjpeg6b-compatible build of libjpeg-turbo, i.e. with
--without-mem-srcdst, would not be sufficient.

If our libjpeg-turbo was built to be libjpeg6b-compatible, most symbols
could be annotated in debian/*.symbols as provided by both IJG libjpeg6b
and libjpeg-turbo, but jpeg_mem_(src|dest) should be annotated as
specifically needing the libjpeg-turbo version (until/unless someone
adds them to Debian's packaging of IJG libjpeg, or releases an upstream
IJG libjpeg 6d with a backport).

It would seem slightly perverse to go back to a libjpeg6b-compatible ABI
when we've just done the transition from 6b to 8, but, whatever. I seem
to remember libjpeg6b is part of the LSB, for what little that's worth.


Reply to: