Summary: | media-libs/openjpeg-2.3.1-r1: broken include path in OpenJPEGConfig.cmake (was: app-text/poppler-20.11.0 compile fails with 'error: openjpeg.h: No such file or directory') | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | sharpshopter |
Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kde, printing, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=718918 | ||
Whiteboard: | fixed in 2.4.0 | ||
Package list: | Runtime testing required: | --- | |
Attachments: |
Full build log
openjpeg patch |
Description
sharpshopter
2020-11-25 00:36:34 UTC
Created attachment 674788 [details]
Full build log
I looked into this a bit further. $ cat /usr/lib64/pkgconfig/libopenjp2.pc prefix=/usr bindir=${prefix}/bin mandir=${prefix}//usr/share/man docdir=${prefix}//usr/share/doc/openjpeg-2.3.1-r1 libdir=${prefix}/lib64 includedir=${prefix}/include/openjpeg-2.3 Name: openjp2 Description: JPEG2000 library (Part 1 and 2) URL: http://www.openjpeg.org/ Version: 2.3.1 Libs: -L${libdir} -lopenjp2 Libs.private: -lm Cflags: -I${includedir} I don't know cmake well, but I can see the make call in configure has "-DENABLE_LIBOPENJPEG=openjpeg2", and the build.ninja file that results has all the incorrect (ie. no leading /usr) include paths for openjpeg. Further I think I have traced in back to /lib64/cmake/openjpeg-2.3/OpenJPEGConfig.cmake not setting OPENJPEG_INCLUDE_DIRS correctly. I think this is the relevant code, but my lack of cmake knowledge means I can't see anything wrong and don't know how to debug this. get_filename_component(SELF_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH) if(EXISTS ${SELF_DIR}/OpenJPEGTargets.cmake) # This is an install tree include(${SELF_DIR}/OpenJPEGTargets.cmake) # We find a relative path from the PKG directory to header files. set(PKG_DIR "/usr/lib64/cmake/openjpeg-2.3") set(INC_DIR "/usr/include/openjpeg-2.3") file(RELATIVE_PATH PKG_TO_INC_RPATH "${PKG_DIR}" "${INC_DIR}") get_filename_component(OPENJPEG_INCLUDE_DIRS "${SELF_DIR}/${PKG_TO_INC_RPATH}" ABSOLUTE) So I worked out how to debug the cmake process, and get this in the output: /usr/lib64/cmake/openjpeg-2.3/OpenJPEGConfig.cmake(35): get_filename_component(OPENJPEG_INCLUDE_DIRS /usr/lib64/cmake/openjpeg-2.3/../../../include/openjpeg-2.3 ABSOLUTE ) So that was a red herring and OPENJPEG_INCLUDE_DIRS is actually correct. So I ran the debugging again and caught the issue. /lib64/cmake/openjpeg-2.3/OpenJPEGConfig.cmake(25): get_filename_component(SELF_DIR /lib64/cmake/openjpeg-2.3/OpenJPEGConfig.cmake PATH ) /lib64/cmake/openjpeg-2.3/OpenJPEGConfig.cmake(26): if(EXISTS /lib64/cmake/openjpeg-2.3/OpenJPEGTargets.cmake ) /lib64/cmake/openjpeg-2.3/OpenJPEGConfig.cmake(28): include(/lib64/cmake/openjpeg-2.3/OpenJPEGTargets.cmake ) /lib64/cmake/openjpeg-2.3/OpenJPEGConfig.cmake(31): set(PKG_DIR /usr/lib64/cmake/openjpeg-2.3 )/lib64/cmake/openjpeg-2.3/OpenJPEGConfig.cmake(32): set(INC_DIR /usr/include/openjpeg-2.3 ) /lib64/cmake/openjpeg-2.3/OpenJPEGConfig.cmake(33): file(RELATIVE_PATH PKG_TO_INC_RPATH /usr/lib64/cmake/openjpeg-2.3 /usr/include/openjpeg-2.3 ) /lib64/cmake/openjpeg-2.3/OpenJPEGConfig.cmake(35): get_filename_component(OPENJPEG_INCLUDE_DIRS /lib64/cmake/openjpeg-2.3/../../../include/openjpeg-2.3 ABSOLUTE ) If this file is accessed via a symlink, this cmake file never canonicalises the SELF_DIR. It pretty much assumes it is /usr/lib64/cmake/openjpeg-2.3 and will produce weird results if that's not the case. So to me this is starting to look like a bug with openjpeg. Looks like there's an upstream issue open for this: https://github.com/uclouvain/openjpeg/issues/1174 I don't really know the process from here. Created attachment 677497 [details, diff]
openjpeg patch
This patch against *openjpeg* fixes this issue for me. It touches lines near what openjpeg-2.3.1-gnuinstalldirs.patch touches too, so not sure if it should be wrapped into that patch and what portage rules on patch application order are (the patch I attached applies after the gnuinstalldirs one).
My fix got merged upstream. Thanks for reporting upstream! |