Blender-3.0.0 is provided in a separate slot from blender-2.93.x Most of the files go into separate `blender-version` folders. Main binary is `/usr/bin/blender-X.Y` When trying to merge both slots with USE="cycles standalone", the second to install package fails with a file collision on `/usr/bin/cycles`. Additionally, there is a compilation warning in intern/cycles/app/cycles_standalone.cpp, which I tried to patch myself. Reproducible: Always Steps to Reproduce: 1. Enable useflags cycles, standalone for both slots 2. Apply a mentioned patch for blender-3.0.0 (else cycles won't compile) 3. Merge both packages Actual Results: The package second to install fails to install. Expected Results: Either name the `/usr/bin/cycles` to `/usr/bin/cycles-X.Y`, perhaps providing a symlink from `/usr/bin/cycles` (and eselect cycles?) Or block *merging* the second slot with USE="cycles standalone".
Created attachment 758383 [details] emerge --info
Created attachment 758384 [details] Full build log resumed after patching manually inside /var/tmp/portage via `sudo ebuild compile` and `sudo ebuild merge`
Created attachment 758385 [details] Partial build log with the compiler warning Possibly should go to a separate bug intern/cycles/util/progress.cpp has a double get_progress(); but intern/cycles/app/cycles_standalone.cpp calls (twice) a float progress... = ... .get_progress();
Created attachment 758386 [details, diff] Bare patch regarding -Werror-conversion I thought to replace float temporaries with double (the actual return type). Might be minor (to display render progress in console)
(In reply to Denis Tolstov from comment #4) > Created attachment 758386 [details, diff] [details, diff] > Bare patch regarding -Werror-conversion > > I thought to replace float temporaries with double (the actual return type). > Might be minor (to display render progress in console) This one got handled as part of bug 830355 (one bug per issue is best so we don't miss stuff). Thanks for the patch though! I'll leave the collision to DarkDefender.
(In reply to Sam James from comment #5) > This one got handled as part of bug 830355 (one bug per issue is best so we > don't miss stuff). Thanks for the patch though! Got handled in bug 830355, which was opened 20 days later, and they never cross-referenced this bug? Fascinating. Nevermind, looks like upstream fixed that in 3.0.1 release. Now I get a linker error for cycles, both 2.93.8 and 3.0.1, should I open another bug about it? Didn't get to install it yet (and run into the collision or confirm resolved). ``` [85/4875] : && /usr/bin/cmake -E rm -f lib/libbf_intern_numaapi.a && /usr/bin/x86_64-pc-linux-gnu-ar qc lib/libbf_intern_numaapi.a intern/numaapi/CMakeFiles/bf_intern_numaapi.dir/source/numaapi.c.o intern/numaapi/CMakeFiles/bf_intern_numaapi.dir/source/numaapi_linux.c.o intern/numaapi/CMakeFiles/bf_intern_numaapi.dir/source/numaapi_stub.c.o intern/numaapi/CMakeFiles/bf_intern_numaapi.dir/source/numaapi_win32.c.o && /usr/bin/x86_64-pc-linux-gnu-ranlib lib/libbf_intern_numaapi.a && : ... [766/4875] : && /usr/lib/distcc/bin/x86_64-pc-linux-gnu-g++ ... -lz -ldl -lpthread -lutil -lc -lm -lpthread -ldl ... lib/libbf_intern_numaapi.a ... -lutil -lc -lm -lpthread ... && : FAILED: bin/cycles : && /usr/lib/distcc/bin/x86_64-pc-linux-gnu-g++ ... /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: lib/libbf_intern_numaapi.a(numaapi_linux.c.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5' /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib64/libdl.so: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status distcc[2196] ERROR: compile (null) on localhost failed ``` But there is a -ldl in the line, twice. `blender[-standalone]` merged fine on another machine.
(In reply to Denis Tolstov from comment #6) > (In reply to Sam James from comment #5) > > This one got handled as part of bug 830355 (one bug per issue is best so we > > don't miss stuff). Thanks for the patch though! > Got handled in bug 830355, which was opened 20 days later, and they never > cross-referenced this bug? Fascinating. > Nevermind, looks like upstream fixed that in 3.0.1 release. > Leave the snark out please, thanks. Yes, it got fixed as a result of it being forwarded upstream. The reporter there didn't think to read a bug with an irrelevant title when hitting a problem. It's not a big deal. > > Now I get a linker error for cycles, both 2.93.8 and 3.0.1, should I open > another bug about it? Didn't get to install it yet (and run into the > collision or confirm resolved). > ``` Yes please.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f9c55a242ac6e8da55f8788d4470c0f30c918a0a commit f9c55a242ac6e8da55f8788d4470c0f30c918a0a Author: Sebastian Parborg <darkdefende@gmail.com> AuthorDate: 2022-05-19 12:42:08 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-05-20 11:25:12 +0000 media-gfx/blender: Remove option to build standalone cycles binary After talking to upstream, it seems like this option is not meant to be use to ship any binaries. It is simply there as an example cycles project that developers can easily modify if they want to quickly code in new features and test them in cycles (without having to go through blender). Closes: https://bugs.gentoo.org/828880 Signed-off-by: Sebastian Parborg <darkdefende@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/25288 Signed-off-by: Joonas Niilola <juippis@gentoo.org> media-gfx/blender/blender-2.93.9.ebuild | 11 +++-------- media-gfx/blender/blender-3.0.1-r5.ebuild | 11 +++-------- media-gfx/blender/blender-3.1.2.ebuild | 11 +++-------- media-gfx/blender/blender-9999.ebuild | 11 +++-------- 4 files changed, 12 insertions(+), 32 deletions(-)
