* [RFC] Use libjpeg-turbo in place of libjpeg
@ 2015-11-27 11:04 Maxin B. John
2015-11-27 11:04 ` [PATCH 1/2] libjpeg: Replace libjpeg with libjpeg-turbo Maxin B. John
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Maxin B. John @ 2015-11-27 11:04 UTC (permalink / raw)
To: openembedded-core
This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.
libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux
distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently.
lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster)
while maintaining same API/ABI as libjpeg.
Once we reach an agreement on this, based on the decision, we can move the
libjpeg package to meta-oe for applications which may depend on API version 9.
[YOCTO #8628]
Maxin B. John (2):
libjpeg: Replace libjpeg with libjpeg-turbo
libjpeg-turbo: import the recipe from meta-oe
meta/recipes-core/jpeg/jpeg_9a.bb | 29 -----------------
meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++
2 files changed, 40 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.1.bb
--
2.4.0
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH 1/2] libjpeg: Replace libjpeg with libjpeg-turbo 2015-11-27 11:04 [RFC] Use libjpeg-turbo in place of libjpeg Maxin B. John @ 2015-11-27 11:04 ` Maxin B. John 2015-11-27 11:04 ` [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe Maxin B. John 2015-11-27 11:13 ` [RFC] Use libjpeg-turbo in place of libjpeg Otavio Salvador 2 siblings, 0 replies; 13+ messages in thread From: Maxin B. John @ 2015-11-27 11:04 UTC (permalink / raw) To: openembedded-core Removing libjpeg from oe-core to replace it with libjpeg-turbo. Signed-off-by: Maxin B. John <maxin.john@intel.com> --- meta/recipes-core/jpeg/jpeg_9a.bb | 29 ----------------------------- 1 file changed, 29 deletions(-) delete mode 100644 meta/recipes-core/jpeg/jpeg_9a.bb diff --git a/meta/recipes-core/jpeg/jpeg_9a.bb b/meta/recipes-core/jpeg/jpeg_9a.bb deleted file mode 100644 index ea2e65d..0000000 --- a/meta/recipes-core/jpeg/jpeg_9a.bb +++ /dev/null @@ -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 -} -- 2.4.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe 2015-11-27 11:04 [RFC] Use libjpeg-turbo in place of libjpeg Maxin B. John 2015-11-27 11:04 ` [PATCH 1/2] libjpeg: Replace libjpeg with libjpeg-turbo Maxin B. John @ 2015-11-27 11:04 ` Maxin B. John 2015-11-27 11:14 ` Martin Jansa ` (2 more replies) 2015-11-27 11:13 ` [RFC] Use libjpeg-turbo in place of libjpeg Otavio Salvador 2 siblings, 3 replies; 13+ messages in thread From: Maxin B. John @ 2015-11-27 11:04 UTC (permalink / raw) To: openembedded-core libjpeg-turbo has same API/ABI as libjpeg. It is relatively faster in JPEG compression/decompression than libjpeg. [YOCTO #8628] Signed-off-by: Maxin B. John <maxin.john@intel.com> --- meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb diff --git a/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb new file mode 100644 index 0000000..e79f800 --- /dev/null +++ b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb @@ -0,0 +1,40 @@ +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] = "b1f6b84859a16b8ebdcda951fa07c3f2" +SRC_URI[sha256sum] = "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08" + +S = "${WORKDIR}/${BPN}-${BASEPV}" + +# Drop-in replacement for jpeg +PROVIDES = "jpeg" +RPROVIDES_${PN} += "jpeg" +RREPLACES_${PN} += "jpeg" +RCONFLICTS_${PN} += "jpeg" + +inherit autotools pkgconfig + +EXTRA_OECONF = "--with-jpeg8 " + +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}/*" + +FILES_libturbojpeg = "${libdir}/libturbojpeg.so" +INSANE_SKIP_libturbojpeg = "dev-so" + +BBCLASSEXTEND = "native" + +LEAD_SONAME = "libjpeg.so.8" -- 2.4.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe 2015-11-27 11:04 ` [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe Maxin B. John @ 2015-11-27 11:14 ` Martin Jansa 2015-11-27 12:20 ` Maxin B. John 2015-11-27 11:43 ` Jussi Kukkonen 2015-11-27 19:51 ` Andre McCurdy 2 siblings, 1 reply; 13+ messages in thread From: Martin Jansa @ 2015-11-27 11:14 UTC (permalink / raw) To: Maxin B. John; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 2764 bytes --] On Fri, Nov 27, 2015 at 01:04:19PM +0200, Maxin B. John wrote: > libjpeg-turbo has same API/ABI as libjpeg. It is relatively > faster in JPEG compression/decompression than libjpeg. Is this imported as-is from meta-oe? If so then at least mention it in commit message and sent libjpeg-turbo removal for meta-oe. > > [YOCTO #8628] > > Signed-off-by: Maxin B. John <maxin.john@intel.com> > --- > meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++ > 1 file changed, 40 insertions(+) > create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > > diff --git a/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > new file mode 100644 > index 0000000..e79f800 > --- /dev/null > +++ b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > @@ -0,0 +1,40 @@ > +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] = "b1f6b84859a16b8ebdcda951fa07c3f2" > +SRC_URI[sha256sum] = "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08" > + > +S = "${WORKDIR}/${BPN}-${BASEPV}" > + > +# Drop-in replacement for jpeg > +PROVIDES = "jpeg" > +RPROVIDES_${PN} += "jpeg" > +RREPLACES_${PN} += "jpeg" > +RCONFLICTS_${PN} += "jpeg" > + > +inherit autotools pkgconfig > + > +EXTRA_OECONF = "--with-jpeg8 " > + > +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}/*" > + > +FILES_libturbojpeg = "${libdir}/libturbojpeg.so" > +INSANE_SKIP_libturbojpeg = "dev-so" > + > +BBCLASSEXTEND = "native" > + > +LEAD_SONAME = "libjpeg.so.8" > -- > 2.4.0 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 188 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe 2015-11-27 11:14 ` Martin Jansa @ 2015-11-27 12:20 ` Maxin B. John 0 siblings, 0 replies; 13+ messages in thread From: Maxin B. John @ 2015-11-27 12:20 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core Hi Martin, On Fri, Nov 27, 2015 at 12:14:52PM +0100, Martin Jansa wrote: > On Fri, Nov 27, 2015 at 01:04:19PM +0200, Maxin B. John wrote: > > libjpeg-turbo has same API/ABI as libjpeg. It is relatively > > faster in JPEG compression/decompression than libjpeg. > > Is this imported as-is from meta-oe? If so then at least mention it in > commit message and sent libjpeg-turbo removal for meta-oe. > Sure, Will do that. This patch set was sent in order to get the opinion from everyone. Will send the libjpeg-turbo removal patch to meta-oe once it is accepted in oe-core. > > > > [YOCTO #8628] > > > > Signed-off-by: Maxin B. John <maxin.john@intel.com> > > --- > > meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++ > > 1 file changed, 40 insertions(+) > > create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > > > > diff --git a/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > > new file mode 100644 > > index 0000000..e79f800 > > --- /dev/null > > +++ b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > > @@ -0,0 +1,40 @@ > > +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] = "b1f6b84859a16b8ebdcda951fa07c3f2" > > +SRC_URI[sha256sum] = "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08" > > + > > +S = "${WORKDIR}/${BPN}-${BASEPV}" > > + > > +# Drop-in replacement for jpeg > > +PROVIDES = "jpeg" > > +RPROVIDES_${PN} += "jpeg" > > +RREPLACES_${PN} += "jpeg" > > +RCONFLICTS_${PN} += "jpeg" > > + > > +inherit autotools pkgconfig > > + > > +EXTRA_OECONF = "--with-jpeg8 " > > + > > +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}/*" > > + > > +FILES_libturbojpeg = "${libdir}/libturbojpeg.so" > > +INSANE_SKIP_libturbojpeg = "dev-so" > > + > > +BBCLASSEXTEND = "native" > > + > > +LEAD_SONAME = "libjpeg.so.8" > > -- > > 2.4.0 > > > > -- > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- > Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com Best Regards, Maxin ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe 2015-11-27 11:04 ` [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe Maxin B. John 2015-11-27 11:14 ` Martin Jansa @ 2015-11-27 11:43 ` Jussi Kukkonen 2015-11-27 19:51 ` Andre McCurdy 2 siblings, 0 replies; 13+ messages in thread From: Jussi Kukkonen @ 2015-11-27 11:43 UTC (permalink / raw) To: Maxin B. John; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 3087 bytes --] On 27 November 2015 at 13:04, Maxin B. John <maxin.john@intel.com> wrote: > libjpeg-turbo has same API/ABI as libjpeg. It is relatively > faster in JPEG compression/decompression than libjpeg. > > [YOCTO #8628] > > Signed-off-by: Maxin B. John <maxin.john@intel.com> > --- > meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 > ++++++++++++++++++++++++ > 1 file changed, 40 insertions(+) > create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > > diff --git a/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > new file mode 100644 > index 0000000..e79f800 > --- /dev/null > +++ b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > @@ -0,0 +1,40 @@ > +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] = "b1f6b84859a16b8ebdcda951fa07c3f2" > +SRC_URI[sha256sum] = > "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08" > + > +S = "${WORKDIR}/${BPN}-${BASEPV}" > + > +# Drop-in replacement for jpeg > +PROVIDES = "jpeg" > +RPROVIDES_${PN} += "jpeg" > +RREPLACES_${PN} += "jpeg" > +RCONFLICTS_${PN} += "jpeg" > + > +inherit autotools pkgconfig > + > +EXTRA_OECONF = "--with-jpeg8 " > It's true that this is closest to what we currently provide but my understanding of the libjpeg changes is this: * Both versions 7 and 8 encoders can produce files that are incompatible with decoders of previous versions * The major additions in 7 and 8 we're never actually accepted at the relevant standards body * most importantly, my impression is that everyone else is using version 6b (this is also jpeg-turbo upstream default) I suggest we default to _not_ supporting jpeg8 or jpeg7. Jussi + > +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}/*" > + > +FILES_libturbojpeg = "${libdir}/libturbojpeg.so" > +INSANE_SKIP_libturbojpeg = "dev-so" > + > +BBCLASSEXTEND = "native" > + > +LEAD_SONAME = "libjpeg.so.8" > -- > 2.4.0 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > [-- Attachment #2: Type: text/html, Size: 4672 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe 2015-11-27 11:04 ` [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe Maxin B. John 2015-11-27 11:14 ` Martin Jansa 2015-11-27 11:43 ` Jussi Kukkonen @ 2015-11-27 19:51 ` Andre McCurdy 2 siblings, 0 replies; 13+ messages in thread From: Andre McCurdy @ 2015-11-27 19:51 UTC (permalink / raw) To: Maxin B. John; +Cc: OE Core mailing list On Fri, Nov 27, 2015 at 3:04 AM, Maxin B. John <maxin.john@intel.com> wrote: > libjpeg-turbo has same API/ABI as libjpeg. It is relatively > faster in JPEG compression/decompression than libjpeg. Please take the libjpeg-turbo 1.4.2 recipe from meta-oe master-next instead of the 1.4.1 recipe from meta-oe master. > [YOCTO #8628] > > Signed-off-by: Maxin B. John <maxin.john@intel.com> > --- > meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++ > 1 file changed, 40 insertions(+) > create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > > diff --git a/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > new file mode 100644 > index 0000000..e79f800 > --- /dev/null > +++ b/meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb > @@ -0,0 +1,40 @@ > +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] = "b1f6b84859a16b8ebdcda951fa07c3f2" > +SRC_URI[sha256sum] = "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08" > + > +S = "${WORKDIR}/${BPN}-${BASEPV}" > + > +# Drop-in replacement for jpeg > +PROVIDES = "jpeg" > +RPROVIDES_${PN} += "jpeg" > +RREPLACES_${PN} += "jpeg" > +RCONFLICTS_${PN} += "jpeg" > + > +inherit autotools pkgconfig > + > +EXTRA_OECONF = "--with-jpeg8 " > + > +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}/*" > + > +FILES_libturbojpeg = "${libdir}/libturbojpeg.so" > +INSANE_SKIP_libturbojpeg = "dev-so" > + > +BBCLASSEXTEND = "native" > + > +LEAD_SONAME = "libjpeg.so.8" > -- > 2.4.0 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Use libjpeg-turbo in place of libjpeg 2015-11-27 11:04 [RFC] Use libjpeg-turbo in place of libjpeg Maxin B. John 2015-11-27 11:04 ` [PATCH 1/2] libjpeg: Replace libjpeg with libjpeg-turbo Maxin B. John 2015-11-27 11:04 ` [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe Maxin B. John @ 2015-11-27 11:13 ` Otavio Salvador 2015-11-27 11:19 ` Martin Jansa 2 siblings, 1 reply; 13+ messages in thread From: Otavio Salvador @ 2015-11-27 11:13 UTC (permalink / raw) To: Maxin B. John; +Cc: Patches and discussions about the oe-core layer On Fri, Nov 27, 2015 at 9:04 AM, Maxin B. John <maxin.john@intel.com> wrote: > This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg. > > libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux > distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently. > lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster) > while maintaining same API/ABI as libjpeg. > > Once we reach an agreement on this, based on the decision, we can move the > libjpeg package to meta-oe for applications which may depend on API version 9. I support this change, due: - agreement with major Linux distros - performance improvement I also think moving libjpeg (API version 9) for meta-oe is fine as well. I am not aware of any application which requires it, though. -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Use libjpeg-turbo in place of libjpeg 2015-11-27 11:13 ` [RFC] Use libjpeg-turbo in place of libjpeg Otavio Salvador @ 2015-11-27 11:19 ` Martin Jansa 2015-11-27 11:21 ` Otavio Salvador ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Martin Jansa @ 2015-11-27 11:19 UTC (permalink / raw) To: Otavio Salvador; +Cc: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 1294 bytes --] On Fri, Nov 27, 2015 at 09:13:22AM -0200, Otavio Salvador wrote: > On Fri, Nov 27, 2015 at 9:04 AM, Maxin B. John <maxin.john@intel.com> wrote: > > This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg. > > > > libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux > > distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently. > > lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster) > > while maintaining same API/ABI as libjpeg. > > > > Once we reach an agreement on this, based on the decision, we can move the > > libjpeg package to meta-oe for applications which may depend on API version 9. > > I support this change, due: > > - agreement with major Linux distros > - performance improvement > > I also think moving libjpeg (API version 9) for meta-oe is fine as > well. I am not aware of any application which requires it, though. I'm not aware of any as well, so I would prefer to drop libjpeg completely. + less junk in meta-oe + people were confused about multiple jpeg providers before, now they would be again, but without good reason (as nobody knows about apps depending on libjpeg9). -- Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 188 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Use libjpeg-turbo in place of libjpeg 2015-11-27 11:19 ` Martin Jansa @ 2015-11-27 11:21 ` Otavio Salvador 2015-11-27 12:22 ` Maxin B. John 2015-11-27 13:54 ` Mike Looijmans 2 siblings, 0 replies; 13+ messages in thread From: Otavio Salvador @ 2015-11-27 11:21 UTC (permalink / raw) To: Martin Jansa; +Cc: Patches and discussions about the oe-core layer On Fri, Nov 27, 2015 at 9:19 AM, Martin Jansa <martin.jansa@gmail.com> wrote: > On Fri, Nov 27, 2015 at 09:13:22AM -0200, Otavio Salvador wrote: >> On Fri, Nov 27, 2015 at 9:04 AM, Maxin B. John <maxin.john@intel.com> wrote: >> > This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg. >> > >> > libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux >> > distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently. >> > lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster) >> > while maintaining same API/ABI as libjpeg. >> > >> > Once we reach an agreement on this, based on the decision, we can move the >> > libjpeg package to meta-oe for applications which may depend on API version 9. >> >> I support this change, due: >> >> - agreement with major Linux distros >> - performance improvement >> >> I also think moving libjpeg (API version 9) for meta-oe is fine as >> well. I am not aware of any application which requires it, though. > > I'm not aware of any as well, so I would prefer to drop libjpeg > completely. > > + less junk in meta-oe > + people were confused about multiple jpeg providers before, now they > would be again, but without good reason (as nobody knows about apps > depending on libjpeg9). Agreed. -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Use libjpeg-turbo in place of libjpeg 2015-11-27 11:19 ` Martin Jansa 2015-11-27 11:21 ` Otavio Salvador @ 2015-11-27 12:22 ` Maxin B. John 2015-11-27 13:54 ` Mike Looijmans 2 siblings, 0 replies; 13+ messages in thread From: Maxin B. John @ 2015-11-27 12:22 UTC (permalink / raw) To: Martin Jansa Cc: Otavio Salvador, Patches and discussions about the oe-core layer Hi, On Fri, Nov 27, 2015 at 12:19:32PM +0100, Martin Jansa wrote: > On Fri, Nov 27, 2015 at 09:13:22AM -0200, Otavio Salvador wrote: > > On Fri, Nov 27, 2015 at 9:04 AM, Maxin B. John <maxin.john@intel.com> wrote: > > > This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg. > > > > > > libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux > > > distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently. > > > lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster) > > > while maintaining same API/ABI as libjpeg. > > > > > > Once we reach an agreement on this, based on the decision, we can move the > > > libjpeg package to meta-oe for applications which may depend on API version 9. > > > > I support this change, due: > > > > - agreement with major Linux distros > > - performance improvement > > > > I also think moving libjpeg (API version 9) for meta-oe is fine as > > well. I am not aware of any application which requires it, though. > > I'm not aware of any as well, so I would prefer to drop libjpeg > completely. > > + less junk in meta-oe > + people were confused about multiple jpeg providers before, now they > would be again, but without good reason (as nobody knows about apps > depending on libjpeg9). > Agree. In this case, I will send a patch to remove libjpeg-turbo from meta-oe. > -- > Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com Best Regards, Maxin ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [RFC] Use libjpeg-turbo in place of libjpeg 2015-11-27 11:19 ` Martin Jansa 2015-11-27 11:21 ` Otavio Salvador 2015-11-27 12:22 ` Maxin B. John @ 2015-11-27 13:54 ` Mike Looijmans 2 siblings, 0 replies; 13+ messages in thread From: Mike Looijmans @ 2015-11-27 13:54 UTC (permalink / raw) To: openembedded-core On 27-11-15 12:19, Martin Jansa wrote: > On Fri, Nov 27, 2015 at 09:13:22AM -0200, Otavio Salvador wrote: >> On Fri, Nov 27, 2015 at 9:04 AM, Maxin B. John <maxin.john@intel.com> wrote: >>> This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg. >>> >>> libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux >>> distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently. >>> lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster) >>> while maintaining same API/ABI as libjpeg. >>> >>> Once we reach an agreement on this, based on the decision, we can move the >>> libjpeg package to meta-oe for applications which may depend on API version 9. >> >> I support this change, due: >> >> - agreement with major Linux distros >> - performance improvement >> >> I also think moving libjpeg (API version 9) for meta-oe is fine as >> well. I am not aware of any application which requires it, though. > > I'm not aware of any as well, so I would prefer to drop libjpeg > completely. > > + less junk in meta-oe > + people were confused about multiple jpeg providers before, now they > would be again, but without good reason (as nobody knows about apps > depending on libjpeg9). Indeed, most (read: "I") have set the PREFERRED_SUPPLIER to "jpeg" just to get rid of the warning message, and not really bothering to check what either meant. I'm in favor of dropping libjpeg completely, it's just confusing. Moving it will lead to package dependency problems when upgrading from one to the other. Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijmans@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 1/2] libjpeg: Replace libjpeg with libjpeg-turbo @ 2015-11-30 9:01 Maxin B. John 0 siblings, 0 replies; 13+ messages in thread From: Maxin B. John @ 2015-11-30 9:01 UTC (permalink / raw) To: openembedded-core Removing libjpeg from oe-core to replace it with libjpeg-turbo. Signed-off-by: Maxin B. John <maxin.john@intel.com> --- meta/recipes-core/jpeg/jpeg_9a.bb | 29 ----------------------------- 1 file changed, 29 deletions(-) delete mode 100644 meta/recipes-core/jpeg/jpeg_9a.bb diff --git a/meta/recipes-core/jpeg/jpeg_9a.bb b/meta/recipes-core/jpeg/jpeg_9a.bb deleted file mode 100644 index ea2e65d..0000000 --- a/meta/recipes-core/jpeg/jpeg_9a.bb +++ /dev/null @@ -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 -} -- 2.4.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-11-30 13:49 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-11-27 11:04 [RFC] Use libjpeg-turbo in place of libjpeg Maxin B. John 2015-11-27 11:04 ` [PATCH 1/2] libjpeg: Replace libjpeg with libjpeg-turbo Maxin B. John 2015-11-27 11:04 ` [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe Maxin B. John 2015-11-27 11:14 ` Martin Jansa 2015-11-27 12:20 ` Maxin B. John 2015-11-27 11:43 ` Jussi Kukkonen 2015-11-27 19:51 ` Andre McCurdy 2015-11-27 11:13 ` [RFC] Use libjpeg-turbo in place of libjpeg Otavio Salvador 2015-11-27 11:19 ` Martin Jansa 2015-11-27 11:21 ` Otavio Salvador 2015-11-27 12:22 ` Maxin B. John 2015-11-27 13:54 ` Mike Looijmans -- strict thread matches above, loose matches on Subject: below -- 2015-11-30 9:01 [PATCH 1/2] libjpeg: Replace libjpeg with libjpeg-turbo Maxin B. John
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.