Created attachment 760945 [details, diff] variable return value patch While rebuilding blender 3.0.0 it generated two errors caused by converting the double values returned by get_progress from double to float: ... /var/tmp/portage/media-gfx/blender-3.0.0/work/blender-3.0.0/intern/cycles/app/cycles_standalone.cpp:85:58: error: conversion from ‘double’ to ‘float’ may change value [-Werror=float-conversion] 85 | float progress = options.session->progress.get_progress(); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ ... /var/tmp/portage/media-gfx/blender-3.0.0/work/blender-3.0.0/intern/cycles/app/cycles_standalone.cpp:186:45: error: conversion from ‘double’ to ‘float’ may change value [-Werror=float-conversion] 186 | float progress_val = progress.get_progress(); | ~~~~~~~~~~~~~~~~~~~~~^~ cc1plus: some warnings being treated as errors ... When I changed the progress and progress_val variable definitions to double it compiled as expected. I will attach the patch and modified ebuild. As a note, the build options are as follows: [ebuild R ~] media-gfx/blender-3.0.0-r1:3.0::EBo-overlays USE="alembic bullet collada color-management cycles dds embree ffmpeg fftw fluid gmp jack jemalloc jpeg2k man nls oidn openal openexr openimageio openmp opensubdiv openvdb osl pdf potrace pugixml pulseaudio sdl sndfile standalone system-numpy system-python tbb tiff -cuda -debug -doc -headless -ndof -test -valgrind" PYTHON_SINGLE_TARGET="python3_9" 0 KiB
Created attachment 760946 [details] modified ebuild with patch
Patches should be merged upstream too. Please inform upstream and add a link to the ticket here.
Is that something you wish me to do, or will one of the maintainers run that up the flag-pole? Just checking so that we do not have several reports for the same issue.
(In reply to John (EBo) David from comment #3) > Is that something you wish me to do, or will one of the maintainers run that > up the flag-pole? Just checking so that we do not have several reports for > the same issue. Would you mind submitting it & popping the link here?
done... Can someone confirm the bug and fix? reported upstream as: https://developer.blender.org/T94563 thanks for everything!
(In reply to John (EBo) David from comment #5) > done... Can someone confirm the bug and fix? > > reported upstream as: https://developer.blender.org/T94563 > > thanks for everything! Thanks a lot! I'm going to see what Sebastian says first and go from there (or if it gets accepted upstream first, so be it, and we'll apply it then). Note that normally we deliberately build without -Werror and such so we might need to somehow disable it, although obviously this is a specific parameter. Wondering why nobdy else has hit it.
That is rather odd. I did not knowingly turn -Werror on. I thought it was just the default onhow you guys set up compiling 3.0.0. Hmmm... anyway, since I have the workaround I can wait until it either is fixed upstream or you patch it. As things go this is trivial.
(In reply to Sam James from comment #6) > Note that normally we deliberately build without -Werror and such so we > might need to somehow disable it, although obviously this is a specific > parameter. Wondering why nobdy else has hit it. So wait, we build with Werror for certain things per default? I'm guessing not many other people have hit this as building cycles as a standalone render is not on per default.
I have not run down where -Werror was set and why, but if that was not expected maybe we should chase that down. I would guess we could turn it on with a IUSE=debug or some such. I have no idea why I caught it now, and why it did not get triggered when I built 2.993...
(In reply to Sebastian Parborg from comment #8) > (In reply to Sam James from comment #6) > > Note that normally we deliberately build without -Werror and such so we > > might need to somehow disable it, although obviously this is a specific > > parameter. Wondering why nobdy else has hit it. > > So wait, we build with Werror for certain things per default? > > I'm guessing not many other people have hit this as building cycles as a > standalone render is not on per default. to be clear: we _don't_ build with -Werror ever, but downstream projects like Blender may add -Werror=XYZ themselves, and we usually don't strip that out when packaging. We do usually strip out blank/catch-all -Werror though.
(In reply to Sam James from comment #10)> > to be clear: we _don't_ build with -Werror ever, but downstream projects > like Blender may add -Werror=XYZ themselves, and we usually don't strip that > out when packaging. We do usually strip out blank/catch-all -Werror though. s/downstream/upstream/...
That explains it then because it was not a blank -Werror, but -Werror=float-conversion specifically. So it was likely added in the Blender build system for 3.0.
Right, so the Werror is from the Blender itself. I confirmed it by grepping the source folder. I will update the upstream ticket.
Just to followup, they are patching the issue upstream. That said, the discussion relieved a number of issues we might want to discuss here. In particular that "standalone" is known to be not stable and they recommend that it not be used at all outside of development at the moment. In addition, they state that there are a number of other switches/options that it does not appear that Gentoo is supporting. We might want to take a serious look at that and see what may need to be pulled in and supported within Gentoo's ebuilds.
(In reply to John (EBo) David from comment #14) > Just to followup, they are patching the issue upstream. That said, the > discussion relieved a number of issues we might want to discuss here. In > particular that "standalone" is known to be not stable and they recommend > that it not be used at all outside of development at the moment. In > addition, they state that there are a number of other switches/options that > it does not appear that Gentoo is supporting. We might want to take a > serious look at that and see what may need to be pulled in and supported > within Gentoo's ebuilds. I'm not too worried about that given sebastian is upstream and I trust him on all of that, but if there's something particular i'm needed for, let me know.
OK. I will mark this as RESOLVED unless you have some reason for me to keep it open.
During an upstream regarding "standalone" being unstable and developer-only, I was give a copy of the blender_release.cmake file to compare what they distribute with their standard release. I have made a table here with what they have on, and what switches we provide. There are 20 instances where we do not have a switch, but two of these (dealing with X11/Xi) are hard requirements in Gentoo's blender install. The remaining 19 are ones we might need to look at and see if they should be turned off/on or additional switches. It is also possible that for the remaining 18, that there are some hard requirements in the DEPEND section that I missed. Regardless, blender has been nothing but unstable for me and it would be nice to figure this out for at least myself if not in general. Hope this is useful. Forced off in blender / set in Gentoo: ASSERT_ABORT debug CYCLES_CUBIN_COMPILER --none -- (only set in Non Apple below, ignore in Gentoo) Forced on in blender / set in Gentoo ALEMBIC alembic AUDASPACE -- none -- BUILDINFO -- none -- BULLET +bullet CODEC_AVI -- none -- CODEC_FFMPEG ffmpg CODEC_SNDFILE sndfile COMPOSITOR -- none -- CYCLES +cycles CYCLES_EMBREE +embree CYCLES_OSL +osl DRACO -- none -- FFTW3 +fftw FREESTYLE -- none -- GMP +gmp HARU +pdf IK_ITASC -- none -- IK_SOLVER -- none -- IMAGE_CINEON -- none -- IMAGE_DDS +dds IMAGE_HDR -- none -- IMAGE_OPENEXR +openexr IMAGE_OPENJPEG jpeg2k IMAGE_TIFF +tiff INPUT_NDOF ndof INPUT_IME -- none -- INTERNATIONAL nls LIBMV -- none -- LIBMV_SCHUR_SPECIALIZATIONS -- none -- LZMA -- none -- LZO (hard requirement ON: dev-libs/lzo:2=) MOD_FLUID +fluid MOD_OCEANSIM fftw MOD_REMESH -- none -- NANOVDB (hard requirement OFF) OPENAL openal OPENCOLLADA collada OPENCOLORIO +color-management OPENIMAGEDENOISE +oidn OPENMP +openmp OPENSUBDIV +opensubdiv OPENVDB +openvdb OPENVDB_BLOSC +openvdb POTRACE +potrace PUGIXML +pugixml PYTHON_INSTALL +system-python <== $(usex system-python OFF ON) flips + numpy QUADRIFLOW -- none -- SDL sdl TBB +tbb USD (hard requirement OFF) MEM_JEMALLOC jemalloc if(NOT WIN32) JACK jack endif() if(UNIX AND NOT APPLE) DOC_MANPAGE doc GHOST_XDND -- none -- PULSEAUDIO pulseaudio X11_XINPUT -- none -- but when not headless require libX11/Xi X11_XF86VMODE -- none -- but when not headless require libXxf86vm endif() if(NOT APPLE) XR_OPENXR (hard requirement OFF) CYCLES_DEVICE_OPTIX -- none -- CYCLES_CUDA_BINARIES +cycles cuda CYCLES_HIP_BINARIES -- none -- endif()
As Brecht pointed out in the upstream bug report, just stating "blender is unstable" doesn't really help with anything. The useflags should at least in theory not make it any more stable/unstable. To figure out what is unstable for you, you have to provide backtraces and steps to reproduce the issue.
sigh... Fair enough. I was trying to work through this and tackle the first things first. I was still trying simply upgrade to the latest supported blender package and turn on/off any switches that seamed reasonable (hence the standalone). My plan next was/is to update all of the potential problematic addons (like Ladybug -- whose new package was only released a day or two ago, and I know I ran into posed bugs that had patches months ago), and then see if it still dies. If so, I will try to give a minimal example to post both here and to the blender folks, and also post any specific error messages, logs, and traces as well. I get that just saying that it has been unstable for me, but I made the comment as an aside as to why I was bothering with this. My posting the CMAKE/ebuild comparison was due to upstream complaining about the use of standalone and posting what they set for their standard release. If any of the missing 18 or so switches have any affect, I have no idea, but I thought I would try to document them in case anyone wants/needs those or if someone knows that missing something causes instability. The one thing that I did get from that is that +ndof +opencl was default, and not set on my build. My guess is that one of the two of them are likely to make some difference. I just rebuilt blender with ndof opencl, and will try to give it another go this weekend. If it works I'll report back here.
I think this is in 3.0.1. Thank you!
@Sam re: upstream 3.0.1 support Excellent! I look forward to the formal release next month or earlier if they release before 3/9 or whenever). For a couple of side notes, upstream suggested that I just use their binary distros. To test that I found the one ebuild hanging around the net, updated it, and published it on one of my github overlays -- so that I can test a gentoo build against their distributed version. While this was done some time ago, I got sick (non-COVID) and still catching up on various things that take a higher priority. Also, if I recall upstream did not want to futz with gentoo source build issues unless there was a reason to. Having the upstream binary installs allows me to test and make sure that the issue is broken on the upstream and not a gentoo issue. Anyway, thanks again Sam and others for pushing to this upstream fixed.
