2018-02-13 16:37 GMT+01:00 Michael Olbrich <m.olbrich@pengutronix.de>:

> Hi,
>
> On Tue, Feb 13, 2018 at 10:23:09AM +0100, Guillermo Rodriguez Garcia wrote:
> > I need to use libjpeg-turbo for some apps that rely on specific
> > libjpeg-turbo extensions that are not available in the standard (IJG's)
> > libjpeg library. So I started to create a set of ptxdist rules for
> > libjpeg-turbo.
> >
> > libjpeg-turbo is supposed to provide a drop-in replacement for the
> standard
> > IJG's libjpeg, and in fact many Linux distributions have already switched
> > to it. So most packages that currently depend on LIBJPEG should be able
> to
> > use libjpeg-turbo as well without any changes.
> >
> > Example: gst-plugins-good1.in currently does the following:
> >
> > select LIBJPEG if GST_PLUGINS_GOOD1_JPEG
> >
> > However, gst-plugins-good1 should work just fine with libjpeg-turbo as
> > well. In fact the upstream gst-plugins already switched to libjpeg-turbo
> > some time ago (see the Cerbero scripts)
> >
> > So, what is the recommended way to approach this in ptxdist? I can
> imagine
> > some options:
> >
> > 1. Provide a separate set of .in/.make files for libjpeg-turbo and a
> > separate LIBJPEG_TURBO package. So new packages that want to use
> > libjpeg-turbo would need to explicitly select LIBJPEG_TURBO (instead of
> > LIBJPEG). But this means that packages that currently use libjpeg would
> not
> > be able to benefit from the performance improvements in libjpeg-turbo.
> Also
> > I am not sure whether these two libraries (libjpeg and libjpeg-turbo) can
> > actually coexist in the same system.
>
> No.
>
> > 2. Modify the LIBJPEG rules to provide an option to select between the
> > standard (IJG) libjpeg, or libjpeg-turbo. This would be similar to what
> is
> > done in alsa.in/alsa.make to select between the "full" and "light"
> versions
> > of the library.
>
> Either this ...
>
> > 3. Other?
>
> ... or change the libjpeg rule to always build libjpeg-turbo instead.
>
> I would prefer to avoid an option. But I'm not sure
> 1. if there are use-cases where libjpeg is preferable
> 2. if there are packages that fail to build with libjpeg-turbo
>

Judging from the wide adoption of libjpeg-turbo by many popular Linux
distros, I'd say that if we had to choose one, libjpeg-turbo may actually
be the "safe" choice.


>
> I have some libjpeg-turbo stuff lying around here somewhere. It was just
> never finished. I've just dumped it in my test BSP so see if anythings
> fails to build. I'll report the result later.
>

Let me know if you need help; I am also working on this now (since I do
have an app that explicitly needs libjpeg-turbo and doesn't work with the
stock libjpeg)

Best,

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com