Building media-libs-4.4.0 errors out with: In file included from /var/tmp/portage/media-libs/opencv-4.4.0/work/opencv-4.4.0/modules/imgcodecs/src/grfmts.hpp:54, from /var/tmp/portage/media-libs/opencv-4.4.0/work/opencv-4.4.0/modules/imgcodecs/src/loadsave.cpp:47: /var/tmp/portage/media-libs/opencv-4.4.0/work/opencv-4.4.0/modules/imgcodecs/src/grfmt_jpeg2000_openjpeg.hpp:13:10: fatal error: openjpeg.h: No such file or directory 13 | #include <openjpeg.h> | ^~~~~~~~~~~~ useflag jpeg2k is NOT set, but media-libs/openjpeg is installed, in case that matters. Reproducible: Always Steps to Reproduce: 1. emerge media-libs/opencv 2. 3. Actual Results: Build fails. Expected Results: Build succeeds.
Created attachment 664444 [details] emerge --info
Created attachment 664447 [details] build.log
Before I start looking into it, does /usr/include/openjpeg.h exists?
Accoring to the build log, opencv is trying to find openjpeg's header files from /include/openjpeg-2.3. This is rather disconcerting. Can you rebuild openjpeg then rebuild opencv and see what happens?
(In reply to Ross Charles C. from comment #3) > Before I start looking into it, does /usr/include/openjpeg.h exists? No, it doesn't, but /usr/include/openjpeg-2.3/openjpeg.h does exists. (In reply to Ross Charles C. from comment #4) > Accoring to the build log, opencv is trying to find openjpeg's header files from > /include/openjpeg-2.3. This is rather disconcerting. Can you rebuild openjpeg then > rebuild opencv and see what happens? Sure! I just rebuild openjpeg and then opencv, but the error persists. I attach the new build log.
Created attachment 664483 [details] build.log (v2)
Possibly relevant: openjpeg is slotted. Port to openjpeg from jasper was done in https://github.com/opencv/opencv/pull/16494, landed in 4.3.0.
I tried building the opencv with the exactly same USE flags as yours, but it still compiles fine. I did notice one thing through, that your system seems to have a different filesystem hierarchy. I haven't seen any FEATURE that can place gcc and ninja(!) at /bin instead of /usr/bin. For your reference, you can compare the difference in the paths of executables and libraries. Mine are basically all dwelling on /usr/{bin,lib64}: -- General configuration for OpenCV 4.4.0 ===================================== -- Version control: unknown -- -- Extra modules: -- Location (extra): /var/tmp/portage/media-libs/opencv-4.4.0/work/opencv_contrib-4.4.0/modules -- Version control (extra): unknown -- -- Platform: -- Timestamp: 2020-10-10T02:01:53Z -- Host: Linux 5.8.11-gentoo-x86_64 x86_64 -- CMake: 3.18.4 -- CMake generator: Ninja -- CMake build tool: /usr/bin/ninja -- Configuration: Gentoo -- -- CPU/HW features: -- Baseline: SSE SSE2 SSE3 SSSE3 SSE4_1 POPCNT SSE4_2 FP16 FMA3 AVX AVX2 -- requested: AVX AVX2 FP16 FMA3 POPCNT SSE SSE2 SSE3 SSSE3 SSE4_1 SSE4_2 -- -- C/C++: -- Built as dynamic libs?: YES -- C++ standard: 11 -- C++ Compiler: /usr/bin/x86_64-pc-linux-gnu-g++ (ver 10.2.0) -- C++ flags (Release): -O2 -pipe -march=native -mtune=native -mtls-dialect=gnu2 -mfpmath=both -fabi-version=14 -fsigned-char -W -Wall -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wuninitialized -Winit-self -Wsuggest-override -Wno-delete-non-virtual-dtor -Wno-comment -Wimplicit-fallthrough=3 -Wno-strict-overflow -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -ffunction-sections -fdata-sections -flto -msse -msse2 -msse3 -mssse3 -msse4.1 -mpopcnt -msse4.2 -mf16c -mfma -mavx -mavx2 -fvisibility=hidden -fvisibility-inlines-hidden -fopenmp -O3 -DNDEBUG -DNDEBUG -- C++ flags (Debug): -O2 -pipe -march=native -mtune=native -mtls-dialect=gnu2 -mfpmath=both -fabi-version=14 -fsigned-char -W -Wall -Werror=return-type -Werror=non-virtual-dtor -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wuninitialized -Winit-self -Wsuggest-override -Wno-delete-non-virtual-dtor -Wno-comment -Wimplicit-fallthrough=3 -Wno-strict-overflow -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -ffunction-sections -fdata-sections -flto -msse -msse2 -msse3 -mssse3 -msse4.1 -mpopcnt -msse4.2 -mf16c -mfma -mavx -mavx2 -fvisibility=hidden -fvisibility-inlines-hidden -fopenmp -g -DDEBUG -D_DEBUG -- C Compiler: /usr/bin/x86_64-pc-linux-gnu-gcc -- C flags (Release): -O2 -pipe -march=native -mtune=native -mtls-dialect=gnu2 -mfpmath=both -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wuninitialized -Winit-self -Wno-comment -Wimplicit-fallthrough=3 -Wno-strict-overflow -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -ffunction-sections -fdata-sections -flto -msse -msse2 -msse3 -mssse3 -msse4.1 -mpopcnt -msse4.2 -mf16c -mfma -mavx -mavx2 -fvisibility=hidden -fopenmp -O3 -DNDEBUG -DNDEBUG -- C flags (Debug): -O2 -pipe -march=native -mtune=native -mtls-dialect=gnu2 -mfpmath=both -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wuninitialized -Winit-self -Wno-comment -Wimplicit-fallthrough=3 -Wno-strict-overflow -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -ffunction-sections -fdata-sections -flto -msse -msse2 -msse3 -mssse3 -msse4.1 -mpopcnt -msse4.2 -mf16c -mfma -mavx -mavx2 -fvisibility=hidden -fopenmp -g -DDEBUG -D_DEBUG -- Linker flags (Release): -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -Wl,--as-needed -- Linker flags (Debug): -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -Wl,--as-needed -- ccache: NO -- Precompiled headers: NO -- Extra dependencies: dl m pthread rt /usr/lib64/libGL.so /usr/lib64/libGLU.so -- 3rdparty dependencies: -- -- OpenCV modules: -- To be built: alphamat aruco bgsegm bioinspired calib3d ccalib core datasets dpm face features2d flann fuzzy hfs highgui img_hash imgcodecs imgproc intensity_transform line_descriptor ml objdetect optflow phase_unwrapping photo plot quality rapid reg rgbd saliency shape stereo stitching structured_light superres surface_matching tracking video videoio videostab ximgproc xobjdetect xphoto -- Disabled: cvv dnn freetype ovis python3 world xfeatures2d -- Disabled by dependency: dnn_objdetect dnn_superres text -- Unavailable: cnn_3dobj cudaarithm cudabgsegm cudacodec cudafeatures2d cudafilters cudaimgproc cudalegacy cudaobjdetect cudaoptflow cudastereo cudawarping cudev gapi hdf java js julia matlab python2 sfm ts viz -- Applications: - -- Documentation: NO -- Non-free algorithms: NO -- -- GUI: -- QT: YES (ver 5.15.1) -- QT OpenGL support: YES (Qt5::OpenGL 5.15.1) -- OpenGL support: YES (/usr/lib64/libGL.so /usr/lib64/libGLU.so) -- -- Media I/O: -- ZLib: /usr/lib64/libz.so (ver 1.2.11) -- JPEG: /usr/lib64/libjpeg.so (ver unknown) -- WEBP: /usr/lib64/libwebp.so (ver encoder: 0x020f) -- PNG: /usr/lib64/libpng.so (ver 1.6.37) -- TIFF: /usr/lib64/libtiff.so (ver 42 / 4.1.0) -- JPEG 2000: OpenJPEG (ver 2.3.1) -- HDR: YES -- SUNRASTER: YES -- PXM: YES -- PFM: YES -- -- Video I/O: -- FFMPEG: YES -- avcodec: YES (58.91.100) -- avformat: YES (58.45.100) -- avutil: YES (56.51.100) -- swscale: YES (5.7.100) -- avresample: YES (4.0.0) -- GStreamer: YES (1.16.2) -- -- Parallel framework: TBB (ver 2020.3 interface 11103) -- -- Trace: YES (built-in) -- -- Other third-party libraries: -- VA: YES -- Intel VA-API/OpenCL: NO -- Eigen: YES (ver 3.3.7) -- Custom HAL: NO -- Protobuf: /usr/lib64/libprotobuf.so (3.13.0) -- -- OpenCL: YES (no extra features) -- Include path: /var/tmp/portage/media-libs/opencv-4.4.0/work/opencv-4.4.0/3rdparty/include/opencl/1.2 -- Link libraries: Dynamic load -- -- Python (for build): /usr/bin/python -- -- Install to: /usr
(In reply to Ross Charles C. from comment #8) > I tried building the opencv with the exactly same USE flags as yours, but it > still compiles fine. > > I did notice one thing through, that your system seems to have a different > filesystem hierarchy. I haven't seen any FEATURE that can place gcc and > ninja(!) at /bin instead of /usr/bin. > They may be running with the "usr merge" but this is usually worth revealing up front ;)
(In reply to Sam James from comment #9) > (In reply to Ross Charles C. from comment #8) > > I tried building the opencv with the exactly same USE flags as yours, but it > > still compiles fine. > > > > I did notice one thing through, that your system seems to have a different > > filesystem hierarchy. I haven't seen any FEATURE that can place gcc and > > ninja(!) at /bin instead of /usr/bin. > > > > They may be running with the "usr merge" but this is usually worth revealing > up front ;) Note that we don't seem to have an openjpeg dependency in the ebuild anyway so it seems real even if this is finding it in the wrong place, no?
(In reply to Sam James from comment #10) > Note that we don't seem to have an openjpeg dependency in the ebuild anyway > so it seems real even if this is finding it in the wrong place, no? Uncaptured dependency indeed. I didn't notice before but the jpeg2k USE flag does neither pulling in any dependency or ticking any cmake definitions. This should be fixed.
Ok this patch fixed the previously overlooked jpeg2k issue by explicitly setting cmake's WITH_OPENJPEG variable, please patch the ebuild and test. diff --git a/media-libs/opencv/opencv-4.4.0.ebuild b/media-libs/opencv/opencv-4.4.0.ebuild index 783f97e3a22..36866f36317 100644 --- a/media-libs/opencv/opencv-4.4.0.ebuild +++ b/media-libs/opencv/opencv-4.4.0.ebuild @@ -110,6 +110,7 @@ RDEPEND=" ) java? ( >=virtual/jre-1.6:* ) jpeg? ( virtual/jpeg:0[${MULTILIB_USEDEP}] ) + jpeg2k? ( media-libs/openjpeg:=[${MULTILIB_USEDEP}] ) lapack? ( virtual/lapack ) opencl? ( virtual/opencl[${MULTILIB_USEDEP}] ) openexr? ( media-libs/openexr[${MULTILIB_USEDEP}] ) @@ -330,6 +331,7 @@ multilib_src_configure() { -DWITH_IPP=OFF -DWITH_JASPER=OFF -DWITH_JPEG=$(usex jpeg) + -DWITH_OPENJPEG=$(usex jpeg2k) -DWITH_WEBP=$(usex webp) -DWITH_OPENEXR=$(usex openexr) -DWITH_OPENGL=$(usex opengl)
(In reply to Ross Charles C. from comment #12) > Ok this patch fixed the previously overlooked jpeg2k issue by explicitly > setting cmake's WITH_OPENJPEG variable, please patch the ebuild and test. This looks fine (although we need :2 on openjpeg), obviously we will wait for the outcome of the test though. I don't really get how /include and /usr/include both exist on OP's system though.
(In reply to Sam James from comment #9) > (In reply to Ross Charles C. from comment #8) > > I tried building the opencv with the exactly same USE flags as yours, but it > > still compiles fine. > > > > I did notice one thing through, that your system seems to have a different > > filesystem hierarchy. I haven't seen any FEATURE that can place gcc and > > ninja(!) at /bin instead of /usr/bin. > > > > They may be running with the "usr merge" but this is usually worth revealing > up front ;) Sorry, your right. It's a system with "usr merge": % ls -lh /|grep '\->' lrwxrwxrwx 1 root root 7 14. Sep 2019 bin -> usr/bin lrwxrwxrwx 1 root root 7 14. Sep 2019 lib -> usr/lib lrwxrwxrwx 1 root root 9 14. Sep 2019 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 8 14. Sep 2019 sbin -> usr/sbin
Just tried compiling with the patched ebuild, worked like a charm. :) Though /include does not exist on my system: # ls -lh / total 20K drwxr-xr-x 1 root root 0 3. Jan 2018 @ lrwxrwxrwx 1 root root 7 14. Sep 2019 bin -> usr/bin drwxr-xr-x 7 root root 4,0K 1. Jan 1970 boot drwxr-xr-x 21 root root 3,8K 10. Okt 11:58 dev drwxr-xr-x 1 root root 3,9K 10. Okt 12:35 etc drwxr-xr-x 1 root root 128 3. Okt 14:30 home lrwxrwxrwx 1 root root 7 14. Sep 2019 lib -> usr/lib lrwxrwxrwx 1 root root 9 14. Sep 2019 lib64 -> usr/lib64 drwxr-xr-x 1 root root 10 3. Mär 2017 media drwxr-xr-x 1 root root 204 18. Apr 16:44 mnt drwxr-xr-x 1 root root 252 15. Mai 14:18 opt dr-xr-xr-x 472 root root 0 10. Okt 11:58 proc drwx------ 1 root root 1,1K 10. Okt 12:40 root drwxr-xr-x 25 root root 640 10. Okt 11:59 run lrwxrwxrwx 1 root root 8 14. Sep 2019 sbin -> usr/sbin drwxr-xr-x 1 root root 8 14. Dez 2018 srv dr-xr-xr-x 12 root root 0 10. Okt 11:58 sys drwxrwxrwt 17 root root 420 10. Okt 12:35 tmp drwxr-xr-x 1 root root 192 6. Dez 2019 usr drwxr-xr-x 1 root root 128 7. Dez 2019 var And here is /usr for good measure: % ls -lhd /usr/* drwxr-xr-x 1 root root 67K 10. Okt 12:35 /usr/bin drwxr-xr-x 1 root root 17K 9. Okt 11:56 /usr/include drwxr-xr-x 1 root root 42K 9. Okt 11:36 /usr/lib drwxr-xr-x 1 root root 134K 10. Okt 12:35 /usr/lib64 drwxr-xr-x 1 root root 1,5K 9. Okt 11:45 /usr/libexec drwxr-xr-x 1 root root 104 26. Nov 2019 /usr/local lrwxrwxrwx 1 root root 20 6. Dez 2019 /usr/portage -> /var/db/repos/gentoo drwxr-xr-x 1 root root 7,1K 9. Okt 11:48 /usr/sbin drwxr-xr-x 1 root root 5,4K 9. Okt 11:48 /usr/share drwxr-xr-x 1 root root 250 21. Feb 2019 /usr/src lrwxrwxrwx 1 root root 8 3. Mär 2017 /usr/tmp -> /var/tmp drwxr-xr-x 1 root root 0 4. Dez 2019 /usr/x86_64-multilib-linux-gnu drwxr-xr-x 1 root root 148 26. Nov 2019 /usr/x86_64-pc-linux-gnu
Created attachment 664498 [details] build.log.zst (success)
(In reply to Jimmy Kloss from comment #15) > Just tried compiling with the patched ebuild, worked like a charm. :) Then it settles. My suspect is that openjpeg's include path is defined relative to the location of its cmake configuration files, and since the configuration files is found at /lib64, the include path will be expanded to /include/openjpeg-2.3. Hence opencv can't find openjpeg.h. This whole usr merge setting is too unorthodox for gentoo and I don't even know how you pulled off building all the dependencies without running into troubles. However my patch works because it disables opencv's dependency on openjpeg as you have already disabled jpeg2k USE flag.
(In reply to Ross Charles C. from comment #17) > (In reply to Jimmy Kloss from comment #15) > > Just tried compiling with the patched ebuild, worked like a charm. :) > > Then it settles. My suspect is that openjpeg's include path is defined > relative to the location of its cmake configuration files, and since the > configuration files is found at /lib64, the include path will be expanded to > /include/openjpeg-2.3. Hence opencv can't find openjpeg.h. > Oh, this sounds oddly familiar. I think there was an issue with mail-client/kube once. I "fixed" it by symlinking /include -> /usr/include, later decided I don't this package anyway and removed it. > This whole usr merge setting is too unorthodox for gentoo and I don't even > know how you pulled off building all the dependencies without running into > troubles. However my patch works because it disables opencv's dependency on > openjpeg as you have already disabled jpeg2k USE flag. Tbh, I consider the whole FSH weird and due for an overhaul, but if distributions could agree upon a standard, there wouldn't be so many of them. ;) As for pulling it of: I guess luck + happily disabling any troublesome USE flag :D
This bug report does expose a flaw on the ebuild through, that jpeg2k USE flag doesn't have effect and opencv's build system will still detect openjpeg automatically. But I noticed on https://github.com/opencv/opencv/milestones that the checklist for 4.5.0 is almost complete so the release is likely to happen within a matter of days or sooner. I will make sure the fix will be included in the 4.5.0 version bump.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=78bcdb12864a1e60ef79d66d1aabf732704450ce commit 78bcdb12864a1e60ef79d66d1aabf732704450ce Author: Sam James <sam@gentoo.org> AuthorDate: 2020-10-11 18:39:01 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2020-10-11 19:16:13 +0000 media-libs/opencv: fix automagic dep on openjpeg USE=jpeg2k was a no-op until now. Bug: https://bugs.gentoo.org/747427 Package-Manager: Portage-3.0.4, Repoman-3.0.1 Signed-off-by: Sam James <sam@gentoo.org> media-libs/opencv/{opencv-4.4.0.ebuild => opencv-4.4.0-r1.ebuild} | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
