Re: [Libjpeg-devel-6x] Support for renaming public API in support of dual 8bit/12bit configurations

[Bob F. <bfr...@si...>]

On Mon, 22 Jun 2009, Tom Lane wrote:
>
> Well, my thought is that you are never going to get anyone to build
> libjpeg 6x that way because they aren't going to want to break all their
> other applications.  With v7 you have a chance to get the capability
> into the "standard" build, where it might do you some good.

My understanding of Frank's approach is that symbols are only renamed 
if libjpeg is built to support 12 bit JPEG, and a special configure 
flag is provided while building the library.  The resulting library is 
built and installed with a unique foot-print.  This means that it 
impacts virtually no-one in the world.

Like it or not, JPEG 6b will be with us for quite some time even when 
JPEG 7 is available.  It takes several years for conservative stable 
Linux distributions (e.g. Debian) to update something as fundamental 
as libjpeg, and many users are likely to lag by another year so we can 
expect that JPEG 6b will remain dominant even on currently maintained 
OSs for at least three years.  Frank's approach allows for adding 
simultaneous 12 bit support for specialized applications without upset 
to the rest of the system.

Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/