2018-02-14 10:22 GMT+01:00 Guillermo Rodriguez Garcia <
guille.rodriguez@gmail.com>:

> Hi Michael,
>
> 2018-02-14 8:49 GMT+01:00 Michael Olbrich <m.olbrich@pengutronix.de>:
>
>> On Tue, Feb 13, 2018 at 05:12:14PM +0100, Guillermo Rodriguez Garcia
>> wrote:
>> > 2018-02-13 16:37 GMT+01:00 Michael Olbrich <m.olbrich@pengutronix.de>:
>> > > 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)
>>
>> My test build looks good. No failed packages. So I pushed what I have to
>> master. Please test it and compare it with what you have so far.
>>
>
> No build issues here and I can confirm that both gst-plugins-good1 (with
> the jpeg plugin) and imagemagick both work fine with libjpeg-turbo on my
> target platform.
>
> Some comments:
>
> - According to the documentation (https://github.com/libjpeg-
> turbo/libjpeg-turbo/blob/master/BUILDING.md), NASM or YASM are required
> if building x86 or x86-64 SIMD extensions. I have not verified this ,yself
> (I'm building for an ARM target) but since we are enabling SIMD, shouldn't
> the .in file select HOST_NASM? (ideally for ARCH_X86 only but it seems that
> this can't be checked in the .in file?)
>
> - For ARM targets, --with-simd requires NEON support. Perhaps the .make
> file should do something like this:
>
> # For ARM, enable SIMD extensions only if NEON is available
> ifdef PTXCONF_ARCH_ARM_NEON
> LIBJPEG_CONF_OPT += --with-simd
> endif
> # For architectures other than ARM, enable SIMD extensions unconditionally
> ifndef PTXCONF_ARCH_ARM
> LIBJPEG_CONF_OPT += --with-simd
> endif
>

BTW one more comment:

If --with-jpeg8 is specified, --with-jpeg7 has no effect. See configure.ac:

  if test "x${with_jpeg8}" = "xyes"; then
    JPEG_LIB_VERSION=80
  else
    if test "x${with_jpeg7}" = "xyes"; then
      JPEG_LIB_VERSION=70
    else
      JPEG_LIB_VERSION=62
    fi
  fi

So you may want to remove --with-jpeg7 from the .make file.

Best,

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com