Summary: | media-gfx/blender-2.93.2 - undefined reference to 'Alembic::AbcGeom::v12::XformSample::setMatrix(Imath_2_5::Matrix44<double> const&)' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Leonid Kopylov <leonchik1976> |
Component: | Current packages | Assignee: | Adrian <agrigo2001> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | darkdefende, lssndrbarbieri, proxy-maint, sam, waebbl-gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 820674 | ||
Attachments: | build.log.xz |
Description
Leonid Kopylov
2021-10-15 07:59:16 UTC
Created attachment 745008 [details]
build.log.xz
Sadly I cannot reproduce this issue. Blender 2.93.2 and the live 9999 version build and runs fine with Alembic support for me. I don't know why your build is failing. See also https://bugs.gentoo.org/818010. It should be noticed that the build system for Blender by default uses ld.gold as the linker. My concern is that the gold linker is not well-maintained now. On the other hand, ld.bfd seems to cause a problem with LTO (https://github.com/InBetweenNames/gentooLTO/issues/381). So my suggestion is to try using ld.lld (sys-devel/lld) as the third option. It might also worth trying another (older) version of binutils than binutils-2.37_p1. My analysis was probably wrong in the above comment. What I have noticed is that my installation of Alembic (=media-gfx/alembic-1.8.2) links against /usr/lib64/Imath-3/libImath-3_1.so, whereas in the case of failure /usr/lib64/libImath-2_5.so is going to be used: -- Found OpenEXR: /usr/lib64/libHalf-2_5.so;/usr/lib64/libIex-2_5.so;/usr/lib64/libIlmImf-2_5.so;/usr/lib64/libIlmThread-2_5.so;/usr/lib64/libImath-2_5.so So I suspect that this might be caused by the version inconsistency of dev-libs/imath used in the dependencies of Blender, namely between media-libs/openexr and media-gfx/alembic. (In reply to Tee KOBAYASHI from comment #4) > My analysis was probably wrong in the above comment. > > What I have noticed is that my installation of Alembic > (=media-gfx/alembic-1.8.2) links against /usr/lib64/Imath-3/libImath-3_1.so, > whereas in the case of failure /usr/lib64/libImath-2_5.so is going to be > used: > > -- Found OpenEXR: > /usr/lib64/libHalf-2_5.so;/usr/lib64/libIex-2_5.so;/usr/lib64/libIlmImf-2_5. > so;/usr/lib64/libIlmThread-2_5.so;/usr/lib64/libImath-2_5.so > > So I suspect that this might be caused by the version inconsistency of > dev-libs/imath used in the dependencies of Blender, namely between > media-libs/openexr and media-gfx/alembic. Interesting. I'm guessing it is openexr >= 3.0 that is pulling in dev-libs/imath on your system? Seems like ilmbase also provides the imath libraries and the alembic ebuild can choose either or which leads to issues :/ I wonder if there is any ebuild mechanisms to detect these sorts of things. There is a similar issue but with llvm versions. However I didn't find any way to detect library issues like that in the blender ebuild last time I looked into it. I'm getting the same build issue: [I] media-gfx/alembic Available versions: 1.8.2^t {examples hdf5 test} Installed versions: 1.8.2^t(22:01:24 16/10/21)(hdf5 -examples -test) Homepage: https://www.alembic.io/ Description: Open framework for storing and sharing scene data [I] media-libs/openexr Available versions: (0) 2.5.6(0/25)^t 2.5.7(0/25)^t (3) (~)3.0.5(3/29)^t (~)3.1.1(3/30)^t {doc examples large-stack static-libs test threads utils ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" CPU_FLAGS_X86="avx"} Installed versions: 2.5.7(0/25)^t(21:41:59 15/10/21)(-doc -examples -static-libs -test -utils ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="32 64 -x32" CPU_FLAGS_X86="avx") 3.1.1(3/30)^t(07:54:19 16/10/21)(-doc -examples -large-stack -static-libs -test -threads -utils CPU_FLAGS_X86="avx") Homepage: https://www.openexr.com/ Description: ILM's OpenEXR high dynamic-range image file format libraries media-gfx/blender Available versions: (2.83) (~)2.83.15^t (~)2.83.16^t (~)2.83.17^t (2.93) (~)2.93.0^t (~)2.93.1^t (~)2.93.2^t (9999) **9999*l^t {abi6-compat abi7-compat alembic +bullet collada (+)color-management cuda (+)cycles +dds debug doc +elbeem +embree (+)ffmpeg (+)fftw +fluid +gmp headless jack jemalloc jpeg2k llvm man ndof nls +oidn openal opencl +openexr (+)openimageio (+)openmp (+)opensubdiv (+)openvdb (+)osl +pdf +potrace +pugixml pulseaudio sdl (+)sndfile standalone +system-numpy +system-python +tbb test (+)tiff valgrind PYTHON_SINGLE_TARGET="python3_10 (+)python3_8 (+)python3_9"} Installed versions: 2.93.2(2.93)^t(02:03:09 11/10/21)(alembic bullet collada color-management cycles dds embree ffmpeg fftw fluid gmp jack jpeg2k nls oidn openal opencl openexr openimageio openmp opensubdiv openvdb osl pdf potrace pugixml pulseaudio sdl sndfile system-numpy system-python tbb tiff -cuda -debug -doc -headless -jemalloc -man -ndof -standalone -test -valgrind PYTHON_SINGLE_TARGET="python3_9") Homepage: https://www.blender.org Description: 3D Creation/Animation/Publishing System [I] dev-libs/imath Available versions: (3) (~)3.0.5-r1(3/28)^t (~)3.1.1(3/29)^t {doc large-stack python static-libs test PYTHON_SINGLE_TARGET="python3_10 python3_8 python3_9"} Installed versions: 3.1.1(3/29)^t(07:53:18 16/10/21)(python -doc -large-stack -static-libs -test PYTHON_SINGLE_TARGET="python3_9 -python3_10 -python3_8") Homepage: https://imath.readthedocs.io Description: Imath basic math package Alembic prefers the use of Imath-3. So if it's available on the system, it will use it. IlmBase is only used as a fallback, if the newer imath isn't present. This could be used as a workaround to force build against the ilmbase libraries, by temporarily removing imath from the system before building alembic and reinstalling it again afterwards. There could be a possibility to add a USE flag, which, if set will use Imath, and if unset use IlmBase, but this will also need some fiddling on their cmake files, most prominently on the AlembicIlmBase.cmake file and probably the main CMakeLists.txt file to handle the added USE flag. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cae650d89e8ff3ceb61818bc90b216339deff77d commit cae650d89e8ff3ceb61818bc90b216339deff77d Author: Sam James <sam@gentoo.org> AuthorDate: 2021-10-31 06:26:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-10-31 06:29:08 +0000 media-gfx/alembic: force use of OpenEXR 2 (ilmbase), not imath for now We want to avoid mismatches within Blender. Closes: https://bugs.gentoo.org/818232 Signed-off-by: Sam James <sam@gentoo.org> .../{alembic-1.8.3.ebuild => alembic-1.8.3-r1.ebuild} | 17 ++++++++--------- profiles/arch/arm/package.use.mask | 4 ++++ profiles/arch/arm64/package.use.mask | 4 ++++ 3 files changed, 16 insertions(+), 9 deletions(-) Sam (or anyone else), I could patch blender it work with openexr 3 and thus work with the imath library as well. However if I do this, then as I pointed out before, we might run into an issue where the user still has a library mismatch between the libraries. So the alembic library might use ilmbase while blender uses imath. Same thing with llvm. Blender will crash for example if mesa uses a different llvm version than some of the libraries blender pulls in. Therefore I think we would need some kind of mechanism in portage were we can check libraries of dependencies. I'm not too sure if this should be solved with useflags as I think it pollutes the options needlessly. I would rather have it be some kind of ebuild settings so you could for example do something like: MATCHING_SLOT_DEPEND=sys-devel/llvm #Checks that all dependencies are using the same llvm slot library NO_DEPEND=dev-libs/imath #No library can depend on imath until support for openexr3 is in blender. Then is will show up as blocked packages when trying to merge blender is there are any conflicts. (In reply to Sebastian Parborg from comment #9) > Sam (or anyone else), I could patch blender it work with openexr 3 and thus > work with the imath library as well. > I would avoid this for now. There's at least openvdb, which is an important dependency of blender, that will support openexr-3 only with the newly released 9.0 and the upcoming 8.2 release. We also have an open issue with oiio and openexr-3 on Gentoo. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cdbdfa031ae9572cc3558609adb4eca5e3508216 commit cdbdfa031ae9572cc3558609adb4eca5e3508216 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-02-12 14:27:53 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-02-12 14:27:53 +0000 media-gfx/alembic: flip over to OpenEXR 3 Things are getting complicated with trying to keep Blender on OpenEXR 2. Blender needs to switch as a result, but so do its dependencies. Bug: https://bugs.gentoo.org/818232 Signed-off-by: Sam James <sam@gentoo.org> media-gfx/alembic/alembic-1.8.3-r2.ebuild | 65 +++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) |