[Libjpeg-turbo-devel] Enabling the in-memory source/destination managers in libjpeg-turbo's default API

[DRC <dco...@us...>]

As you probably know, Fedora is considering enabling the jpeg-8 
emulation mode in libjpeg-turbo.  I raised concerns about this primarily 
because they are the first distro (at least, as far as I'm aware) that 
has proposed switching to the jpeg-8 ABI after already switching to 
libjpeg-turbo.  For all of the others, using the jpeg-8 emulation mode 
in libjpeg-turbo was intended to preserve at least some API/ABI 
compatibility with a previous version of the O/S that had already made 
the switch to jpeg-8.  In this case, Fedora has been retaining backward 
compatibility with jpeg-6b all this time, so there is no actual 
technical reason for the upgrade except that one package, libkdcraw, 
requires the in-memory source/destination managers in jpeg-8 (why that 
library couldn't have just included the in-memory source/dest managers 
in its source code, I have no idea.  jpeg_mem_src() and jpeg_mem_dest() 
are fully self-contained.)

Anyway, it's not necessarily that there are any technical problems 
associated with Fedora switching to the jpeg-8 API (they would provide 
backward compatibility via a -compat package.)  It's just that I am 
concerned that moving to the jpeg-8 API implies support of the jpeg-8 
features, including the non-standard SmartScale format, and the fact 
that libjpeg-turbo doesn't support those features (and it's looking more 
likely that we never will) means that the JPEG library in Fedora will 
appear incomplete or broken.  Seems like a long way to go around the 
block just to allow one library to use the in-memory source/destination 
managers.

So the idea that was proposed was to add just the jpeg_mem_src() and 
jpeg_mem_dest() functions to the existing (libjpeg v6b-compatible) API 
in libjpeg-turbo.  In the past, I have gotten some requests to provide 
binaries with jpeg-8 emulation enabled solely for the purposes of using 
the in-memory source/dest managers, so being able to provide those 
functions in the official libjpeg-turbo binaries would make a few users 
happy at least.  If the code wasn't being built with jpeg-8 emulation, 
then these functions would be optionally enabled with a configure/CMake 
flag.

The question I had was:  what are the best practices for accomplishing 
this while retaining backward compatibility for applications that don't 
use those functions?  On Linux at least, it can be taken care of with 
the version script, but not on Mac and Windows.  Would we need to bump 
the library version?  If so, to what?  (it's currently libjpeg.so.62.0.0 
on Linux/BSD/etc., libjpeg.62.0.0.dylib on OS X, jpeg62.dll for Visual 
C++, and libjpeg62.dll for MinGW.)  At least on Windows, there isn't any 
concept of library versioning, so the choices are:  (1) add functions 
and risk an application not working if it uses those functions and tries 
to link with an older version of the DLL at run time, or (2) change the 
DLL name, thus making all previous software unable to use it at run 
time.  Either way, it's DLL hell, but since neither libjpeg or 
libjpeg-turbo are "system" libraries on Windows, it's probably not that 
big of a deal.  Windows applications are probably always going to 
distribute their own copy of the DLL or statically link.  Thus, I have a 
slight preference toward not changing the DLL name, which would mean 
keeping the JPEG library version at "62", but of course the "age" or 
"revision" could be bumped on Mac or Linux to indicate the API 
incompatibility.

Comments?  I confess that I'm not an expert on library versioning.

DRC