In those cases, the situation is really no different from using
VirtualGL/TurboVNC on a system that doesn't have libjpeg-turbo. It
would be technically possible to add an option to where VirtualGL and
TurboVNC could be built with the system's version of libjpeg-turbo, but
that would require moving the TurboJPEG wrapper back into the TurboVNC
and VirtualGL code bases. It was moved out of there for a good reason:
because it was a royal pain to maintain it in three places.
It would be nice if distro maintainers such as Fedora and ArchLinux
would include TurboJPEG/OSS as a separate, optional package, rather than
simply deleting it from their builds.
On 7/27/11 8:36 AM, DRC wrote:
> Please don't confuse "libjpeg-turbo" with "TurboJPEG", as they are not
> the same thing.
> libjpeg-turbo describes the overall libjpeg-turbo open source project,
> as well as the specific library that provides a SIMD-accelerated
> implementation of the industry-standard libjpeg API/ABI.
> TurboJPEG is a higher-level API used by VirtualGL and TurboVNC (and some
> other projects as well.) The specific implementation of this API
> provided by libjpeg-turbo is called "TurboJPEG/OSS", but other
> implementations exist, such as TurboJPEG/mediaLib and TurboJPEG/IPP,
> which are built on top of proprietary technologies.
> Fedora also packages libjpeg-turbo without TurboJPEG/OSS. It just means
> that you have to either install one of the libjpeg-turbo pre-built
> packages or build and install libjpeg-turbo from source to get the
> TurboJPEG/OSS wrapper library.
> On 7/27/11 1:31 AM, Arthur Huillet wrote:
>> I thought you might be interested in seeing the following report I made about
>> Archlinux's TurboJPEG package:
>> Archlinux has replaced libjpeg with turbojpeg by default, but the package is
>> mangled in a manner that makes it very confusing when you try to do development
>> on TurboVNC or VirtualGL because libturbojpeg.so is not available.