[3/165] /usr/bin/x86_64-pc-linux-gnu-g++ -DOpenImageIO_EXPORTS -DOpenImageIO_Util_EXPORTS -DUSE_EXTERNAL_PUGIXML=1 -DUSE_FREETYPE=1 -DUSE_JPEG_TURBO=1 -DUSE_OCIO=1 -DUSE_OPENCOLORIO=1 -DUSE_STD_REGEX -DUSE_TBB=1 -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/var/tmp/portage/media-libs/openimageio-2.2.18.0/work/openimageio-2.2.18.0_build/include/OpenImageIO -I/var/tmp/portage/media-libs/openimageio-2.2.18.0/work/openimageio-2.2.18.0_build/include -I/var/tmp/portage/media-libs/openimageio-2.2.18.0/work/openimageio-2.2.18.0_build/src/include -I/var/tmp/portage/media-libs/openimageio-2.2.18.0/work/oiio-Release-2.2.18.0/src/include -isystem /usr/include/Imath-3 -pipe -march=native -fno-diagnostics-color -O2 -fPIC -Wall -Wno-unused-local-typedefs -Wno-unused-result -Wno-aligned-new -Wno-noexcept-type -fno-math-errno -maes -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mf16c -std=c++11 -MD -MT src/libutil/CMakeFiles/OpenImageIO_Util.dir/argparse.cpp.o -MF src/libutil/CMakeFiles/OpenImageIO_Util.dir/argparse.cpp.o.d -o src/libutil/CMakeFiles/OpenImageIO_Util.dir/argparse.cpp.o -c /var/tmp/portage/media-libs/openimageio-2.2.18.0/work/oiio-Release-2.2.18.0/src/libutil/argparse.cpp ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_no_multilib_hardened-j4-20210930-222637 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-11.2.0 * clang version 13.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/13/bin /usr/lib/llvm/13 13.0.0 Python 3.9.7 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby30 (with Rubygems) * Available Rust versions: [1] rust-1.55.0 * The Glorious Glasgow Haskell Compilation System, version 8.10.4 php cli: HEAD of ::gentoo commit ca9b541a9317cfeb3fd8baf3cd4abd95506b1333 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Mon Oct 4 01:51:27 2021 +0000 2021-10-04 01:51:25 UTC emerge -qpvO media-libs/openimageio [ebuild N ] media-libs/openimageio-2.2.18.0 USE="gif truetype -X -dicom -doc -ffmpeg -field3d -jpeg2k -opencv -opengl -openvdb -ptex -python -qt5 -raw" CPU_FLAGS_X86="aes avx avx2 f16c sse2 sse3 sse4_1 sse4_2 ssse3 -avx512f" PYTHON_SINGLE_TARGET="python3_9 -python3_8 -python3_10"
Created attachment 742944 [details] emerge-info.txt
Created attachment 742947 [details] emerge-history.txt
Created attachment 742950 [details] environment
Created attachment 742953 [details] etc.portage.tar.bz2
Created attachment 742956 [details] logs.tar.bz2
Created attachment 742959 [details] media-libs:openimageio-2.2.18.0:20211004-025830.log
Created attachment 742962 [details] temp.tar.bz2
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9a199d0effa80199b193914ca95bba2dbbd35a91 commit 9a199d0effa80199b193914ca95bba2dbbd35a91 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-10-06 02:42:32 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-10-06 02:43:03 +0000 media-libs/openimageio: require older openexr Even the latest version (2.3.8.0) upstream doesn't seem to pick up imath right now. Bug: https://bugs.gentoo.org/816264 Signed-off-by: Sam James <sam@gentoo.org> .../{openimageio-2.2.12.0.ebuild => openimageio-2.2.12.0-r1.ebuild} | 2 +- .../{openimageio-2.2.13.1.ebuild => openimageio-2.2.13.1-r1.ebuild} | 2 +- .../{openimageio-2.2.14.0.ebuild => openimageio-2.2.14.0-r1.ebuild} | 2 +- .../{openimageio-2.2.15.0.ebuild => openimageio-2.2.15.0-r1.ebuild} | 2 +- .../{openimageio-2.2.15.1.ebuild => openimageio-2.2.15.1-r1.ebuild} | 2 +- .../{openimageio-2.2.18.0.ebuild => openimageio-2.2.18.0-r1.ebuild} | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-)
It should work with openexr-3, see for example https://github.com/OpenImageIO/oiio/pull/3100, which is about brand new OpenEXRCore C library only available in 3.1+.
I assume this is because the import referenced in the error: <Imath/ImathColor.h>, is installed as Imath-3/ImathColor.h on my system.
I'm having the same issue, and find when I do something like `ln -s /usr/include/Imath-3 /usr/include/Imath` to try resolve the include error, and it instead fails later on in the build due to a symbol error (the namespace appears to have changed from Imath to Imath_3_1 for me). It seems like openimageio might not be presently compatible with new versions of imath/openexr.
Obviously the co-existence of the two media-libs/openexr versions on a system (one from slot 0 -> media-libs/openexr-2.5.7 and one from slot 3 -> media-libs/openexr-3.1.1) is not handled well in the build of media-libs/openimageio-2.2.18.0-r1 ... A temp workaround till it is fixed, is to remove slot 3 of media-libs/openexr, emerge media-libs/openimageio and then re-emerge slot 3. i.e. emerge -C media-libs/openexr:3 emerge -v media-libs/openimageio emerge -v media-libs/openexr:3 That temporary fixed the problem for me....
Thank you, PhobosK, that worked for me. I was chasing it in the wrong direction, trying to make changes in dev-libs/imath to fix it, since it provides the files that the error message was referring to.
OpenEXR is currently missing several keywords as well to be able to be supported well by OIIO. OIIO has proper support for both Imath-3 and OpenEXR-3, but expects the header files to be found in the standard locations /usr/include/{Imath,OpenEXR}, while we add a -3 suffix to be able to have the package slotted. So the ebuild would need a few additional quirks to build against slot 3 of the packages.
Created attachment 744303 [details, diff] oiio-diff-r1-r2.patch I did some testing on the package. It will build successfully in most cases with this patch applied, even against packages (like ocio, opencv) which are built against ilmbase/openexr:0. There are two exceptions, however. Field3D and OpenVDB will not build with this patch against openexr:3, due to namespace collisions. I tested with all USE flags enabled, and field3d and openvdb USE flags disabled and it build successfully for me. We might think about whether we want to mask the two USE flags until their packages are updated, or live with a build against openexr:0. The other lines in the patch, ensure that the selected python is used (cmake will use the highest available) and to use C++14 if >=openvdb-8 is installed. The latter will need to be added, once we have an OpenVDB which builds against imath/openexr:3.
(In reply to Bernd from comment #15) > Created attachment 744303 [details, diff] [details, diff] > oiio-diff-r1-r2.patch > > I did some testing on the package. It will build successfully in most cases > with this patch applied, even against packages (like ocio, opencv) which are > built against ilmbase/openexr:0. > > There are two exceptions, however. Field3D and OpenVDB will not build with > this patch against openexr:3, due to namespace collisions. I tested with all > USE flags enabled, and field3d and openvdb USE flags disabled and it build > successfully for me. > > We might think about whether we want to mask the two USE flags until their > packages are updated, or live with a build against openexr:0. > Sure, let's do that. > The other lines in the patch, ensure that the selected python is used (cmake > will use the highest available) and to use C++14 if >=openvdb-8 is > installed. The latter will need to be added, once we have an OpenVDB which > builds against imath/openexr:3. Thanks. Fancy doing it as a PR?
I can add it to my list
These ebuild changes allow openimageio to build, however if trying to build OSL, it will fail choking on some C++14 related macros for constexprs in imath: /usr/include/Imath-3/half.h:571:5: error: ‘IMATH_CONSTEXPR14’ does not name a type; did you mean ‘OIIO_CONSTEXPR14’? 571 | IMATH_CONSTEXPR14 half round (unsigned int n) const IMATH_NOEXCEPT; | ^~~~~~~~~~~~~~~~~ | OIIO_CONSTEXPR14 /usr/include/Imath-3/half.h:624:18: error: ‘IMATH_CONSTEXPR14’ does not name a type; did you mean ‘OIIO_CONSTEXPR14’? 624 | IMATH_EXPORT IMATH_CONSTEXPR14 void setBits (uint16_t bits) IMATH_NOEXCEPT; | ^~~~~~~~~~~~~~~~~ | OIIO_CONSTEXPR14 /usr/include/Imath-3/half.h:670:8: error: ‘IMATH_CONSTEXPR14’ does not name a type; did you mean ‘OIIO_CONSTEXPR14’? 670 | inline IMATH_CONSTEXPR14 half | ^~~~~~~~~~~~~~~~~ | OIIO_CONSTEXPR14 /usr/include/Imath-3/half.h:880:8: error: ‘IMATH_CONSTEXPR14’ does not name a type; did you mean ‘OIIO_CONSTEXPR14’? 880 | inline IMATH_CONSTEXPR14 void | ^~~~~~~~~~~~~~~~~ | OIIO_CONSTEXPR14
*** Bug 820275 has been marked as a duplicate of this bug. ***
See https://bugs.gentoo.org/820275#c4 too.
*** Bug 820509 has been marked as a duplicate of this bug. ***
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e61be0af4c50f28ffe45f506edf4cebc93df47a8 commit e61be0af4c50f28ffe45f506edf4cebc93df47a8 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-10-31 05:43:25 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-10-31 05:43:48 +0000 media-libs/openimageio: add 2.3.8.0 Closes: https://bugs.gentoo.org/816264 Bug: https://bugs.gentoo.org/810703 Signed-off-by: Sam James <sam@gentoo.org> media-libs/openimageio/Manifest | 1 + media-libs/openimageio/openimageio-2.3.8.0.ebuild | 168 ++++++++++++++++++++++ 2 files changed, 169 insertions(+)
For now, I've gone for building against :0 even though it stinks, just because at least that _works_. Upstream have done considerable work to get their CMake stuff working with both versions of OpenEXR but it semed to not want to pick up OpenEXR 3 for me..
The problem seems to be still present in media-libs/openimageio-2.2.19.0
(In reply to Marco Napetti from comment #24) > The problem seems to be still present in media-libs/openimageio-2.2.19.0 Please upload the build.log and emerge —-info.
Created attachment 748611 [details] build.log
Created attachment 748614 [details] emerge --info '=media-libs/openimageio-2.2.19.0::gentoo'
emerge -pqv '=media-libs/openimageio-2.2.19.0::gentoo' [ebuild U ] media-libs/openimageio-2.2.19.0 [2.2.18.0] USE="X gif opengl qt5 truetype -dicom -doc -ffmpeg -field3d -jpeg2k -opencv -openvdb -ptex -python -raw" CPU_FLAGS_X86="aes avx avx2 f16c sse2 sse3 sse4_1 sse4_2 ssse3 -avx512f" PYTHON_SINGLE_TARGET="python3_9 -python3_8 -python3_10"
I have the same problem with both 2.2.19.0, and 2.2.18.0-r1
Created attachment 748656 [details] openimageio-2.2.18.0-r1 build.log
Created attachment 748659 [details] emerge --info '=media-libs/openimageio-2.2.18.0-r1'
Created attachment 748662 [details] emerge -pqv '=media-libs/openimageio-2.2.18.0-r1'
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ef7884410b54b7c9d64de39095a60c8f27a3f0cd commit ef7884410b54b7c9d64de39095a60c8f27a3f0cd Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-04 20:50:02 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-04 20:50:24 +0000 media-libs/openimageio: avoid finding OpenEXR 3 for 2.2.{18,19} too Bug: https://bugs.gentoo.org/816264 Signed-off-by: Sam James <sam@gentoo.org> media-libs/openimageio/openimageio-2.2.18.0-r1.ebuild | 9 +++++++++ media-libs/openimageio/openimageio-2.2.19.0.ebuild | 9 +++++++++ 2 files changed, 18 insertions(+)
Please retry.
Solved for me
(In reply to Marco Napetti from comment #35) > Solved for me Thank you!
Thanks for the updating. It works for me.
