libjpeg: Replace libjpeg with libjpeg-turbo

PATCH Superseded Maxin B. John 4 participants 8 messages Dec 2, 2015 – Dec 7, 2015

Share & tools

Maxin B. John

author

2015-12-02 12:44 UTC #0 lore raw

PATCH v3 1/1 libjpeg: Replace libjpeg with libjpeg-turbo

Moving libjpeg-turbo from meta-oe as a replacement for libjpeg package. libjpeg-turbo has same API/ABI as libjpeg. It is relatively faster in JPEG compression/decompression than libjpeg.

Changes in v2:
a) Squash the two libjpeg related commits into one

Changes in v3:
a) Use libjpeg-turbo version 1.4.2
b) Build libjpeg-turbo with libjpeg v6b ABI which is commonly used by other major distributions.

[YOCTO #8628]

Signed-off-by Maxin B. John <[email protected]>

---
 meta/recipes-core/jpeg/jpeg_9a.bb                | 29 -------------------
 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.2.bb | 36 ++++++++++++++++++++++++
 2 files changed, 36 insertions(+), 29 deletions(-)
 delete mode 100644 meta/recipes-core/jpeg/jpeg_9a.bb
 create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.2.bb

meta/recipes-core/jpeg/jpeg_9a.bb deleted +0 ~~-29~~

deleted file mode 100644
index ea2e65d..0000000
@@ -1,29 +0,0 @@
-SUMMARY = "libjpeg is a library for handling the JPEG (JFIF) image format"
-DESCRIPTION = "libjpeg contains a library for handling the JPEG (JFIF) image format, as well as related programs for accessing the libjpeg functions."
-HOMEPAGE = "http://www.ijg.org/"
-
-LICENSE ="BSD-3-Clause"
-LIC_FILES_CHKSUM = "file://README;md5=ea93a8a2fed10106b63bc21679edacb9"
-
-SECTION = "libs"
-
-SRC_URI = "http://www.ijg.org/files/jpegsrc.v${PV}.tar.gz \
-	  "
-
-SRC_URI[md5sum] = "3353992aecaee1805ef4109aadd433e7"
-SRC_URI[sha256sum] = "3a753ea48d917945dd54a2d97de388aa06ca2eb1066cbfdc6652036349fe05a7"
-
-inherit autotools
-
-PACKAGES =+ 		"jpeg-tools "
-DESCRIPTION_jpeg-tools = "The jpeg-tools package includes the client programs for access libjpeg functionality.  These tools allow for the compression, decompression, transformation and display of JPEG files."
-FILES_jpeg-tools = 	"${bindir}/*"
-
-BBCLASSEXTEND = "native"
-
-pkg_postinst_${PN}_linuxstdbase () {
-    if [ ! -e $D${libdir}/libjpeg.so.62 ]; then
-        JPEG=`find $D${libdir} -type f -name libjpeg.so.\*.\*.\*`
-        ln -sf `basename $JPEG` $D${libdir}/libjpeg.so.62
-    fi
-}

meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.2.bb new file +36 -0

new file mode 100644
index 0000000..0947763
@@ -0,0 +1,36 @@
+DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression"
+HOMEPAGE = "http://libjpeg-turbo.org/"
+
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \
+                    file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \
+                    file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \
+"
+
+DEPENDS = "nasm-native"
+
+BASEPV = "${@d.getVar('PV',True).split('+')[1]}"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz"
+SRC_URI[md5sum] = "86b0d5f7507c2e6c21c00219162c3c44"
+SRC_URI[sha256sum] = "521bb5d3043e7ac063ce3026d9a59cc2ab2e9636c655a2515af5f4706122233e"
+
+S = "${WORKDIR}/${BPN}-${BASEPV}"
+
+# Drop-in replacement for jpeg
+PROVIDES = "jpeg"
+RPROVIDES_${PN} += "jpeg"
+RREPLACES_${PN} += "jpeg"
+RCONFLICTS_${PN} += "jpeg"
+
+inherit autotools pkgconfig
+
+PACKAGES =+ "jpeg-tools libturbojpeg"
+
+DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programs to access libjpeg functionality.  These tools allow for the compression, decompression, transformation and display of JPEG files and benchmarking of the libjpeg library."
+FILES_jpeg-tools = "${bindir}/*"
+
+DESCRIPTION_libturbojpeg = "A SIMD-accelerated JPEG codec which provides only TurboJPEG APIs"
+FILES_libturbojpeg = "${libdir}/libturbojpeg.so.*"
+
+BBCLASSEXTEND = "native"

Signature · 1 line

2.4.0

Otavio Salvador

2015-12-02 12:56 UTC #1 lore raw

Quoted 7 lines · Maxin B. John

Moving libjpeg-turbo from meta-oe as a replacement for libjpeg package. libjpeg-turbo has same API/ABI as libjpeg. It is relatively faster in JPEG compression/decompression than libjpeg.
Changes in v2:
a) Squash the two libjpeg related commits into one

Quoted 8 lines

Changes in v3:
a) Use libjpeg-turbo version 1.4.2
b) Build libjpeg-turbo with libjpeg v6b ABI which is commonly used by other major distributions.
[YOCTO #8628]
Signed-off-by Maxin B. John <[email protected]>

Please move the Changes out of the commit log; you should send it adding it after --- so it is not applied.

Signature · 3 lines

Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Burton, Ross

2015-12-04 09:12 UTC #3 lore raw

In reply to Maxin B. John

Hi Maxin,

Quoted 4 lines · Maxin B. John

Moving libjpeg-turbo from meta-oe as a replacement for libjpeg package. libjpeg-turbo has same API/ABI as libjpeg. It is relatively faster in JPEG compression/decompression than libjpeg.

As jpeg-turbo has assembler bits it's getting all confused about x32:

| checking if we have SIMD optimisations for cpu type... yes (x86_64)
| checking for nasm... nasm
| checking for object file format of host system... ELF64
| checking for object file format specifier (NAFLAGS) ... -felf64 -DELF

-D__x86_64__
| checking whether the assembler (nasm -felf64 -DELF -D__x86_64__) works... yes
| checking whether the linker accepts assembler output... no
| configure: error: configuration problem: maybe object file format mismatch.

(https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/545)

Ross

Maxin B. John

author

2015-12-04 10:50 UTC #4 lore raw

Hi Ross,

Quoted 19 lines · Ross

Hi Maxin,
Quoted 6 lines · Maxin B. John
Moving libjpeg-turbo from meta-oe as a replacement for libjpeg
package. libjpeg-turbo has same API/ABI as libjpeg. It is
relatively faster in JPEG compression/decompression than libjpeg.
As jpeg-turbo has assembler bits it's getting all confused about x32:
           | checking if we have SIMD optimisations for cpu type... yes (x86_64)
           | checking for nasm... nasm
           | checking for object file format of host system... ELF64
           | checking for object file format specifier (NAFLAGS) ... -felf64 -DELF -D__x86_64__
           | checking whether the assembler (nasm -felf64 -DELF -D__x86_64__) works... yes
           | checking whether the linker accepts assembler output... no
           | configure: error: configuration problem: maybe object file format mismatch.

Quoted 1 line

(https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/545)

There was a discussion about supporting x32 support in libjpeg-turbo:
http://sourceforge.net/p/libjpeg-turbo/patches/35/

Due to some reasons, that ended up in "closed-wont-integrate".

Work-around could be to build with "--without-simd" for x32 or implement the x32 assembly SIMD routines to support that feature (long and painful).

Quoted 1 line

Ross

Best Regards,
Maxin

Burton, Ross

2015-12-04 10:58 UTC #5 lore raw

Quoted 9 lines · Maxin B. John

There was a discussion about supporting x32 support in libjpeg-turbo:
http://sourceforge.net/p/libjpeg-turbo/patches/35/
Due to some reasons, that ended up in "closed-wont-integrate".
Work-around could be to build with "--without-simd" for x32 or implement the x32 assembly SIMD
routines to support that feature (long and painful).

Looks like that was closed because the patch made it compile but failed to actually work. --without-simd for x32 is clearly the right thing to do.

Ross

Burton, Ross

2015-12-07 22:57 UTC #6 lore raw

In reply to Maxin B. John

Quoted 4 lines · Maxin B. John

 meta/recipes-core/jpeg/jpeg_9a.bb                | 29 -------------------
 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.2.bb | 36

++++++++++++++++++++++++

(CCing the usual suspects who will notice and care about this)

I've just noticed that this means that when the binary packages are debian-renamed the version goes backwards: libjpeg-9a to libjpeg-8d+1.4.2. Does anyone have an opinion on either:

1) ignore it
2) put an PE (epoch) in libjpeg-turbo
3) configure the debian renaming so the library has a different name (libjpeg-turbo, presumably)

Ross

Martin Jansa

2015-12-07 23:07 UTC #7 lore raw

Quoted 7 lines · Ross

Quoted 4 lines · Maxin B. John

 meta/recipes-core/jpeg/jpeg_9a.bb                | 29 -------------------
 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.2.bb | 36

++++++++++++++++++++++++

Quoted 7 lines

(CCing the usual suspects who will notice and care about this)
I've just noticed that this means that when the binary packages are debian-renamed the version goes backwards: libjpeg-9a to libjpeg-8d+1.4.2. Does anyone have an opinion on either:
1) ignore it

I'm ok with ignoring it, because all DISTROs I care about were always using libjpeg-turbo.

Quoted 5 lines

2) put an PE (epoch) in libjpeg-turbo
3) configure the debian renaming so the library has a different name (libjpeg-turbo, presumably)
Ross

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]