[meta-oe] jasper: upgrade 2.0.33 -> 4.1.1

* We have to pass "__STDC_VERSION__"  value to cmake option due to this error ->

A cross-compiling environment has been detected.
CMake Error at CMakeLists.txt:430 (message):
	The value of __STDC_VERSION__ cannot be automatically determined when
	cross-compiling.  Please set JAS_STDC_VERSION to the value of
	__STDC_VERSION__ when invoking CMake (e.g., by using the option
	-DJAS_STDC_VERSION=...) or modify the CMakeLists.txt appropriately

* Options that are on by default have been added to PACKAGECONFIG.

Changelog:

4.1.1 (2023-11-28)
==================

* Disallow in-source builds by default.
* Fix a potential integer overflow problem in the jas_get_total_mem_size
  function (for the Windows platform).

4.1.0 (2023-11-04)
==================

* Add support for building several JasPer application programs for
  WebAssembly target with WASI support.

4.0.1 (2023-11-04)
==================

* Fix integer overflow bug in PNM decoder (#353).
* Fix a few minor build issues.

4.0.0 (2022-11-05)
==================

* Improve static linking (#336).
* Fix path relocation in mingw environment (#335).
* Improve logging and build scripts.
* Improve JPEG-2000 conformance test results.
* Enable PIC by default.
* Fix memory leaks in function cmdopts_parse (#332) (CVE-2022-2963).
* imgcmp:
  + Add quiet (-q) option.
  + Add debug-level option.
  + Fix memory leak.
* imginfo:
  + Add quiet (-q) option.
* Fix bug in parsing PGX header.
* Fix integer overflow bug (#345) (CVE-2022-40755).

3.0.6 (2022-07-13)
==================

* Fix bug in manual deployment script.

3.0.5 (2022-06-23)
==================

* Fix a minor build issue (#328).

3.0.4 (2022-06-02)
==================

* Eliminate some bogus calls to abort.
* Fix a typo in jas_safeui64_div (#323).
* Add some additional logging messages.
* Fix the source of a potential compiler warning (#321).

3.0.3 (2022-03-15)
==================

* Fix some portability issues in a few scripts.

3.0.2 (2022-02-14)
==================

* Fix a build issue that occurs when a cross-compiler is used (e.g., #319).

3.0.1 (2022-02-12)
==================

* Fix some build/portability issues (e.g., #317, #318).

3.0.0 (2022-02-05)
==================

VERY IMPORTANT NOTE:
This release of the JasPer software introduced some changes in the API
and/or behavior of the library relative to earlier releases, which may
necessitate some small changes in code using the library (e.g., to avoid
memory leaks or other problems).  Please refer to the "News" section
of the JasPer Reference Manual for more details.  For convenience,
this manual is available online (for various JasPer releases) at:
    https://jasper-software.github.io/jasper-manual

* Greatly improve documentation.
* Add support for multithreading.
* Add some customization points in the library, such as the memory allocator
  and error logging function.
* Add improved memory usage tracking and limiting.
* Add experimental partial encoding/decoding support for the HEIC format.
* Fix some longstanding issues in the JasPer I/O streams API.
* Add the running of the full test suite in CI builds for the Windows platform.
  (Previously, the full test suite was only run for CI builds on Unix-based
  platforms.)
* Fix many bugs (e.g., #305, #307, #308, #309, #312, #314, and many others
  not associated with any issue numbers).

* Merged support for JasPer 3.0.0 into the XV software at:
      https://github.com/jasper-software/xv.git

Signed-off-by: alperak <alperyasinak1@gmail.com>
---
 .../recipes-graphics/jasper/jasper_2.0.33.bb  | 26 -----------
 .../recipes-graphics/jasper/jasper_4.1.1.bb   | 45 +++++++++++++++++++
 2 files changed, 45 insertions(+), 26 deletions(-)
 delete mode 100644 meta-oe/recipes-graphics/jasper/jasper_2.0.33.bb
 create mode 100644 meta-oe/recipes-graphics/jasper/jasper_4.1.1.bb

> On 4 Dec 2023, at 19:52, Alper Ak via lists.openembedded.org <alperyasinak1=gmail.com@lists.openembedded.org> wrote:
> 
> -CVE_STATUS[CVE-2015-8751] = "fixed-version: The CPE in the NVD database doesn't reflect correctly the vulnerable versions.”

Why is this line deleted?  The CVE still doesn’t record versions, so this will make the issue reappear in the report.

Ross

> -do_install:append() {
> -    chrpath -d ${D}${bindir}/jasper
> -    chrpath -d ${D}${bindir}/imginfo
> -    chrpath -d ${D}${bindir}/imgcmp
> -    chrpath -d ${D}${libdir}/libjasper.so.*
> -}

Are these no longer needed? Or did they get deleted accidentally?  As it stands, I can’t tell.

> +PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl', '', d)} \
> +   shared-lib PIC hidden jpeg heif opengl doc latex programs multithread pthread bmp jp2 jpc jpg pgx pnm ras \
> +  "
> +  
> +PACKAGECONFIG[shared-lib] = "-DJAS_ENABLE_SHARED=ON,-DJAS_ENABLE_SHARED=OFF,,"
> +PACKAGECONFIG[PIC] = "-DJAS_ENABLE_PIC=ON,-DJAS_ENABLE_PIC=OFF,,"
> +PACKAGECONFIG[hidden] = "-DJAS_ENABLE_HIDDEN=ON,-DJAS_ENABLE_HIDDEN=OFF,,"
> +PACKAGECONFIG[32bit] = "-DJAS_ENABLE_32BIT=ON,-DJAS_ENABLE_32BIT=OFF,,"
> +PACKAGECONFIG[jpeg] = "-DJAS_ENABLE_LIBJPEG=ON,-DJAS_ENABLE_LIBJPEG=OFF,jpeg,"
> +PACKAGECONFIG[heif] = "-DJAS_ENABLE_LIBHEIF=ON,-DJAS_ENABLE_LIBHEIF=OFF,,"
> +PACKAGECONFIG[opengl] = "-DJAS_ENABLE_OPENGL=ON,-DJAS_ENABLE_OPENGL=OFF,freeglut,"
> +PACKAGECONFIG[doc] = "-DJAS_ENABLE_DOC=ON,-DJAS_ENABLE_DOC=OFF,doxygen,"
> +PACKAGECONFIG[latex] = "-DJAS_ENABLE_LATEX=ON,-DJAS_ENABLE_LATEX=OFF,,"
> +PACKAGECONFIG[programs] = "-DJAS_ENABLE_PROGRAMS=ON,-DJAS_ENABLE_PROGRAMS=OFF,,"
> +PACKAGECONFIG[multithread] = "-DJAS_ENABLE_MULTITHREADING_SUPPORT=ON,-DJAS_ENABLE_MULTITHREADING_SUPPORT=OFF,,"
> +PACKAGECONFIG[pthread] = "-DJAS_PREFER_PTHREAD=ON,-DJAS_PREFER_PTHREAD=OFF,,"
> +PACKAGECONFIG[pthread-tss] = "-DJAS_PREFER_PTHREAD_TSS=ON,-DJAS_PREFER_PTHREAD_TSS=OFF,,"
> +PACKAGECONFIG[strict] = "-DJAS_STRICT=ON,-DJAS_STRICT=OFF,,"
> +PACKAGECONFIG[bmp] = "-DJAS_ENABLE_BMP_CODEC=ON,-DJAS_ENABLE_BMP_CODEC=OFF,,"
> +PACKAGECONFIG[jp2] = "-DJAS_ENABLE_JP2_CODEC=ON,-DJAS_ENABLE_JP2_CODEC=OFF,,"
> +PACKAGECONFIG[jpc] = "-DJAS_ENABLE_JPC_CODEC=ON,-DJAS_ENABLE_JPC_CODEC=OFF,,"
> +PACKAGECONFIG[jpg] = "-DJAS_ENABLE_JPG_CODEC=ON,-DJAS_ENABLE_JPG_CODEC=OFF,,"
> +PACKAGECONFIG[heic] = "-DJAS_ENABLE_HEIC_CODEC=ON,-DJAS_ENABLE_HEIC_CODEC=OFF,,"
> +PACKAGECONFIG[mif] = "-DJAS_ENABLE_MIF_CODEC=ON,-DJAS_ENABLE_MIF_CODEC=OFF,,"
> +PACKAGECONFIG[pgx] = "-DJAS_ENABLE_PGX_CODEC=ON,-DJAS_ENABLE_PGX_CODEC=OFF,,"
> +PACKAGECONFIG[pnm] = "-DJAS_ENABLE_PNM_CODEC=ON,-DJAS_ENABLE_PNM_CODEC=OFF,,"
> +PACKAGECONFIG[ras] = "-DJAS_ENABLE_RAS_CODEC=ON,-DJAS_ENABLE_RAS_CODEC=OFF,,”

Just because there can be an option doesn't mean we should expose it.  We should always build a shared library, we should always build PIC code, we should already support threads, etc.  Docs should be guarded on the api-documentation DISTRO_FEATURE. Arguably some of the format support options could remain (based on the prior art of JPEG) but notably that means dependencies, which is why it was added in the first place. But on the whole we don’t want to expose _every_ option in the recipe, just the ones that make sense.  Remember users of the recipe can easily add their own if they need to control the recipe even further.

Whilst I’m looking, if this is a library that ships with some tools then the tools should always be built (that would be the programs config, I guess) but the recipe should inherit lib_package so that they’re put into a separate package and only installed if needed.

Ross

> Why is this line deleted?  The CVE still doesn’t record versions, so this will make the issue reappear in the report.

Deleted accidentally, my fault. I'll be more careful next time.

> Are these no longer needed? Or did they get deleted accidentally?  As it stands, I can’t tell.

The reason I deleted it is because there is a line in CMakeLists.txt
like "set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")" and that
sets the runpath. If "foo.so" is not present in the runpath, as far as
I know, every shared library is searched in the following locations:
rpath -> LD_LIBRARY_PATH -> runpath -> ld.so.conf -> /lib and /usr/lib
by default. I don't think there's any point in deleting the runpath.

CMakeLists.txt ->
https://github.com/jasper-software/jasper/blob/917f7708b755d8434f70618108c1a76f1b6a0a82/CMakeLists.txt#L809

> Just because there can be an option doesn't mean we should expose it.  We should always build a shared library, we should always build PIC code, we should already support threads, etc.  Docs should be guarded on the api-documentation DISTRO_FEATURE. Arguably some of the format support options could remain (based on the prior art of JPEG) but notably that means dependencies, which is why it was added in the first place. But on the whole we don’t want to expose _every_ option in the recipe, just the ones that make sense.  Remember users of the recipe can easily add their own if they need to control the recipe even further.
>
> Whilst I’m looking, if this is a library that ships with some tools then the tools should always be built (that would be the programs config, I guess) but the recipe should inherit lib_package so that they’re put into a separate package and only installed if needed.

I thought the user should know every option. "Docs should be guarded
on the api-documentation DISTRO_FEATURE", I don't understand exactly
what this means. Thank you for feedback.

Best regards


Ross Burton <Ross.Burton@arm.com>, 4 Ara 2023 Pzt, 23:21 tarihinde şunu yazdı:
>
> > -do_install:append() {
> > -    chrpath -d ${D}${bindir}/jasper
> > -    chrpath -d ${D}${bindir}/imginfo
> > -    chrpath -d ${D}${bindir}/imgcmp
> > -    chrpath -d ${D}${libdir}/libjasper.so.*
> > -}
>
> Are these no longer needed? Or did they get deleted accidentally?  As it stands, I can’t tell.
>
> > +PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl', '', d)} \
> > +   shared-lib PIC hidden jpeg heif opengl doc latex programs multithread pthread bmp jp2 jpc jpg pgx pnm ras \
> > +  "
> > +
> > +PACKAGECONFIG[shared-lib] = "-DJAS_ENABLE_SHARED=ON,-DJAS_ENABLE_SHARED=OFF,,"
> > +PACKAGECONFIG[PIC] = "-DJAS_ENABLE_PIC=ON,-DJAS_ENABLE_PIC=OFF,,"
> > +PACKAGECONFIG[hidden] = "-DJAS_ENABLE_HIDDEN=ON,-DJAS_ENABLE_HIDDEN=OFF,,"
> > +PACKAGECONFIG[32bit] = "-DJAS_ENABLE_32BIT=ON,-DJAS_ENABLE_32BIT=OFF,,"
> > +PACKAGECONFIG[jpeg] = "-DJAS_ENABLE_LIBJPEG=ON,-DJAS_ENABLE_LIBJPEG=OFF,jpeg,"
> > +PACKAGECONFIG[heif] = "-DJAS_ENABLE_LIBHEIF=ON,-DJAS_ENABLE_LIBHEIF=OFF,,"
> > +PACKAGECONFIG[opengl] = "-DJAS_ENABLE_OPENGL=ON,-DJAS_ENABLE_OPENGL=OFF,freeglut,"
> > +PACKAGECONFIG[doc] = "-DJAS_ENABLE_DOC=ON,-DJAS_ENABLE_DOC=OFF,doxygen,"
> > +PACKAGECONFIG[latex] = "-DJAS_ENABLE_LATEX=ON,-DJAS_ENABLE_LATEX=OFF,,"
> > +PACKAGECONFIG[programs] = "-DJAS_ENABLE_PROGRAMS=ON,-DJAS_ENABLE_PROGRAMS=OFF,,"
> > +PACKAGECONFIG[multithread] = "-DJAS_ENABLE_MULTITHREADING_SUPPORT=ON,-DJAS_ENABLE_MULTITHREADING_SUPPORT=OFF,,"
> > +PACKAGECONFIG[pthread] = "-DJAS_PREFER_PTHREAD=ON,-DJAS_PREFER_PTHREAD=OFF,,"
> > +PACKAGECONFIG[pthread-tss] = "-DJAS_PREFER_PTHREAD_TSS=ON,-DJAS_PREFER_PTHREAD_TSS=OFF,,"
> > +PACKAGECONFIG[strict] = "-DJAS_STRICT=ON,-DJAS_STRICT=OFF,,"
> > +PACKAGECONFIG[bmp] = "-DJAS_ENABLE_BMP_CODEC=ON,-DJAS_ENABLE_BMP_CODEC=OFF,,"
> > +PACKAGECONFIG[jp2] = "-DJAS_ENABLE_JP2_CODEC=ON,-DJAS_ENABLE_JP2_CODEC=OFF,,"
> > +PACKAGECONFIG[jpc] = "-DJAS_ENABLE_JPC_CODEC=ON,-DJAS_ENABLE_JPC_CODEC=OFF,,"
> > +PACKAGECONFIG[jpg] = "-DJAS_ENABLE_JPG_CODEC=ON,-DJAS_ENABLE_JPG_CODEC=OFF,,"
> > +PACKAGECONFIG[heic] = "-DJAS_ENABLE_HEIC_CODEC=ON,-DJAS_ENABLE_HEIC_CODEC=OFF,,"
> > +PACKAGECONFIG[mif] = "-DJAS_ENABLE_MIF_CODEC=ON,-DJAS_ENABLE_MIF_CODEC=OFF,,"
> > +PACKAGECONFIG[pgx] = "-DJAS_ENABLE_PGX_CODEC=ON,-DJAS_ENABLE_PGX_CODEC=OFF,,"
> > +PACKAGECONFIG[pnm] = "-DJAS_ENABLE_PNM_CODEC=ON,-DJAS_ENABLE_PNM_CODEC=OFF,,"
> > +PACKAGECONFIG[ras] = "-DJAS_ENABLE_RAS_CODEC=ON,-DJAS_ENABLE_RAS_CODEC=OFF,,”
>
> Just because there can be an option doesn't mean we should expose it.  We should always build a shared library, we should always build PIC code, we should already support threads, etc.  Docs should be guarded on the api-documentation DISTRO_FEATURE. Arguably some of the format support options could remain (based on the prior art of JPEG) but notably that means dependencies, which is why it was added in the first place. But on the whole we don’t want to expose _every_ option in the recipe, just the ones that make sense.  Remember users of the recipe can easily add their own if they need to control the recipe even further.
>
> Whilst I’m looking, if this is a library that ships with some tools then the tools should always be built (that would be the programs config, I guess) but the recipe should inherit lib_package so that they’re put into a separate package and only installed if needed.
>
> Ross

On 5 Dec 2023, at 12:34, alper ak <alperyasinak1@gmail.com> wrote:
> The reason I deleted it is because there is a line in CMakeLists.txt
> like "set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")" and that
> sets the runpath. If "foo.so" is not present in the runpath, as far as
> I know, every shared library is searched in the following locations:
> rpath -> LD_LIBRARY_PATH -> runpath -> ld.so.conf -> /lib and /usr/lib
> by default. I don't think there's any point in deleting the runpath.

Typically we don’t like rpaths in binaries at all, unless there’s a good reason.  There is logic in there to only set the RPATHs if the target isn’t a “system” directory, but if the sanity checker didn’t start throwing warnings then maybe the need for the RPATH removal has gone.

> I thought the user should know every option.

No: some packages have a _lot_ of options and we may want them always on or always off, or have ways to control them implicitly without an explicit PACKAGECONFIG.

> "Docs should be guarded
> on the api-documentation DISTRO_FEATURE", I don't understand exactly
> what this means. 

Like this (made up example):

PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'api-documentation', ‘docs', '', d)}”
PACKAGECONFIG[docs] = “-Ddocs=true,-Ddocs=false,doxygen-native”

Cheers,
Ross