Re: libjpeg-turbo coexistence?

[David Brownlee <abs%absd.org@localhost>]

On Fri, 7 Jan 2022 at 08:54, David Sainty <david.sainty%gmail.com@localhost> wrote:
>
> On Fri, 7 Jan 2022 at 11:58, David Brownlee <abs%absd.org@localhost> wrote:
> >
> > On Tue, 4 Jan 2022 at 23:43, Frederic Fauberteau <triaxx%netbsd.org@localhost> wrote:
> > >
> > > When I look at Debian side, it seems that libjpeg-turbo is the default (and the only one) implementation of JPEG.
> >
> > So... possible options include:
> > 1) Just make libjpeg-turbo the default
> > 2) Split libjpeg-turbo into a base package for libturbojpeg.so and
> > another for libjpeg.so (possibly the base one could install it's
> > libjpeg.so into $PREFIX/lib/libjpeg-turbo/ and the second package just
> > adds symlinks)
> > 3) Have libjpeg-turbo install it's libjpeg.so into
> > $PREFIX/lib/libjpeg-turbo and play games with pkgconfig files to point
> > to there
> >
> > If Debian has switched to entirely using libjpeg-turbo, then I suspect
> > that pretty much all of the issues have been worked out, so I'd be
> > inclined towards 1)...
>
> I think #2 is a separate issue - but it's probably possible to be lazy
> and not do #2 if we do #1.  I'm not sure #3 can be made to work
> safely, which is probably the reason Debian has fully gone with just
> libjpeg-turbo.
>
> If doing #1 it should probably be validated across architectures
> Pkgsrc supports (or turned on for specific architectures only) as
> libjpeg-turbo is crammed full of chip-specific hand-crafted assembly.

It looks like non arm/i386/mips/mips64/powerpc/x86_64 the simd code
will be excluded with a "Performance will suffer." build warning
(unless you have set REQUIRE_SIMD), so it _should_ be OK on all the
VAX & Atari-TT machines out there :-p

David