blender-3.0.0 compilation error on progress.get_progress() return values #94563

New Issue

System Information
Operating system: Gentoo Linux
Graphics card: GeForce GTX 970M

Blender Version
Broken: 3.0.0
Worked: 2.93

When building blender with WITH_CYCLES_STANDALONE the build will fail with:
intern/cycles/app/cycles_standalone.cpp:186:45: error: conversion from ‘double’ to ‘float’ may change value [-Werror=float-conversion]
The get_progress() method is defined to return a double, The simple fix is to change the two instances of the get_process calls to return doubles, or alternatively change the get_progress to return a float.

This bug has been reported to the Blender Gentoo build manager (see: https:*bugs.gentoo.org/830355 ) with workaround patch supplied (see: https:*830355.bugs.gentoo.org/attachment.cgi?id=760945 )

Exact steps for others to reproduce the error

Compile blender with WITH_CYCLES_STANDALONE
Get compile fails with build error.

**System Information** Operating system: Gentoo Linux Graphics card: GeForce GTX 970M **Blender Version** Broken: 3.0.0 Worked: 2.93 When building blender with `WITH_CYCLES_STANDALONE` the build will fail with: `intern/cycles/app/cycles_standalone.cpp:186:45: error: conversion from ‘double’ to ‘float’ may change value [-Werror=float-conversion]` The get_progress() method is defined to return a double, The simple fix is to change the two instances of the get_process calls to return doubles, or alternatively change the get_progress to return a float. This bug has been reported to the Blender Gentoo build manager (see: https:*bugs.gentoo.org/830355 ) with workaround patch supplied (see: https:*830355.bugs.gentoo.org/attachment.cgi?id=760945 ) **Exact steps for others to reproduce the error** 1. Compile blender with `WITH_CYCLES_STANDALONE` 2. Get compile fails with build error.

Added subscriber: @EBo

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Added subscriber: @mano-wii

This issue was referenced by 7d26cf01f7

This issue was referenced by 7d26cf01f78cff7ccc3190125106c9c492f97d6b

This issue was referenced by f7a0f6a0e4

This issue was referenced by f7a0f6a0e4bf4d9233d9fdabf603793288e15d0d

Changed status from 'Needs Developer To Reproduce' to: 'Resolved'

Gentoo should not be building Cycles standalone for their package. It's not stable enough or ready to be installed as part of a Blender package, we do not provide any support for it.

I'll commit a fix for this build issue though.

Gentoo should not be building Cycles standalone for their package. It's not stable enough or ready to be installed as part of a Blender package, we do not provide any support for it. I'll commit a fix for this build issue though.

Added subscriber: @ZedDB

@brecht if it is not supported or stable, then perhaps we should hide the build option as an advanced build flag?

Just in case it is useful I will load build log for review{F12790559}? Also thank you for the note about Cycles standalone being unstable --I have had nothing but grief with trying to run Ladybug and BlenderGIS. I'll try hacking to remove Cycles standalone. I just wonder if there are other issues as well.

As a note, I ran into some online info and ended up setting the use flags for media-gfx/blender "alembic collada jemalloc man -ndof standalone". I'm rebuilding with -standalone. Are there any other suggestions of what to set, unset? The following are all the gentoo use flags included in the new build:

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 system-numpy system-python tbb tiff -cuda -debug -doc -headless -ndof -standalone* -test -valgrind" PYTHON_SINGLE_TARGET="python3_9"

Building with -standalone built to completion without the patch.

Just in case it is useful I will load build log for review{[F12790559](https://archive.blender.org/developer/F12790559/build.log)}? Also thank you for the note about Cycles standalone being unstable --I have had nothing but grief with trying to run Ladybug and BlenderGIS. I'll try hacking to remove Cycles standalone. I just wonder if there are other issues as well. As a note, I ran into some online info and ended up setting the use flags for media-gfx/blender "alembic collada jemalloc man -ndof standalone". I'm rebuilding with -standalone. Are there any other suggestions of what to set, unset? The following are all the gentoo use flags included in the new build: ``` 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 system-numpy system-python tbb tiff -cuda -debug -doc -headless -ndof -standalone* -test -valgrind" PYTHON_SINGLE_TARGET="python3_9" ``` Building with -standalone built to completion without the patch.

Added subscriber: @LazyDodo

not sure how the gentoo flags map to our cmake flags, but you can find the flags we ship with in this file

https://developer.blender.org/diffusion/B/browse/master/build_files/cmake/config/blender_release.cmake

There's a few more like WITH_CYCLES_STANDALONE and WITH_CYCLES_STANDALONE_GUI but those are off by default.

not sure how the gentoo flags map to our cmake flags, but you can find the flags we ship with in this file https://developer.blender.org/diffusion/B/browse/master/build_files/cmake/config/blender_release.cmake There's a few more like `WITH_CYCLES_STANDALONE` and `WITH_CYCLES_STANDALONE_GUI` but those are off by default.

Thank you. I was looking for recommendations for the most stable, or baring that what other options are known to cause instabilities.

Blender would be stable regardless, we try not to ship crashy components :) The instability brecht referred to of cycles standalone is in its API there's no versioning to speak of so may change on a whim, unless you really really really want to use cycles as a library and know what you are getting your self into, we don't recommend building it.

Fair enough. I have only used blender a handful of times and still consider myself quite a noob. I forget if one of the tools I had wanted to use was in a new modeling project did not work in 2.93, or if it was be stumbling into the following warning:

QA Notice: This package installs one or more .desktop files that do not
pass validation.

 /usr/share/applications/blender-3.0.desktop: warning: key "X-KDE-RunOnDiscreteGpu" in group "Desktop Entry" is deprecated

QA Notice: Package triggers severe warnings which indicate that it

       may exhibit random runtime failures.

/var/tmp/portage/media-gfx/blender-3.0.0-r1/work/blender-3.0.0/source/blender/editors/uvedit/uvedit_parametrizer.c:4456:26: warning: array subscript [4, 2147483646] is outside array bounds of ��float *- �� [-Warray-bounds]
Please do not file a Gentoo bug and instead report the above QA
issues directly to the upstream developers of this software.
Homepage: https://www.blender.org

While I was getting blender-3.0.0 compiled I stumbled onto the compilation error, figuring that I would inquire about "X-KDE-RunOnDiscreteGpu" after I resolved the compile error and had a chance to resolve the compilation error and see if that stabilized blender (I am having crashes on 2.93 and 3.00 while working through the Ladybug walk-through demo modeling the thermal load onto building faces using EWP weather data input). Anyway, I have not made time to go back and rerun through the demo and see if I can get it working around it crashing. Blender for me has been unstable for a long time. I just have not tried to get it stable because I did not have a clear and present need. At the moment I want to parametric model a passive solar greenhouse, and use a variety of ML techniques for multi-criteria optimization. This is what motivated me to pick this back up.

Fair enough. I have only used blender a handful of times and still consider myself quite a noob. I forget if one of the tools I had wanted to use was in a new modeling project did not work in 2.93, or if it was be stumbling into the following warning: * QA Notice: This package installs one or more .desktop files that do not * pass validation. * * /usr/share/applications/blender-3.0.desktop: warning: key "X-KDE-RunOnDiscreteGpu" in group "Desktop Entry" is deprecated * * QA Notice: Package triggers severe warnings which indicate that it * may exhibit random runtime failures. * /var/tmp/portage/media-gfx/blender-3.0.0-r1/work/blender-3.0.0/source/blender/editors/uvedit/uvedit_parametrizer.c:4456:26: warning: array subscript [4, 2147483646] is outside array bounds of ��float *- [x]�� [-Warray-bounds] * Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: https://www.blender.org While I was getting blender-3.0.0 compiled I stumbled onto the compilation error, figuring that I would inquire about "X-KDE-RunOnDiscreteGpu" after I resolved the compile error and had a chance to resolve the compilation error and see if that stabilized blender (I am having crashes on 2.93 and 3.00 while working through the Ladybug walk-through demo modeling the thermal load onto building faces using EWP weather data input). Anyway, I have not made time to go back and rerun through the demo and see if I can get it working around it crashing. Blender for me has been unstable for a long time. I just have not tried to get it stable because I did not have a clear and present need. At the moment I want to parametric model a passive solar greenhouse, and use a variety of ML techniques for multi-criteria optimization. This is what motivated me to pick this back up.

If you want the most stable/complete Blender build, it's most straightforward to download the build from blender.org instead of building your own. Even with all use flags the gentoo package still misses some things compared to the official release.

In any case, issues specific to the gentoo package are not handled in this bug tracker.

In #94563#1283448, @ZedDB wrote:
@brecht if it is not supported or stable, then perhaps we should hide the build option as an advanced build flag?

The advanced cmake options are currently used mainly for features that only Blender developers would ever enable. I think this should remain easier to discover than that.

If you want the most stable/complete Blender build, it's most straightforward to download the build from blender.org instead of building your own. Even with all use flags the gentoo package still misses some things compared to the official release. In any case, issues specific to the gentoo package are not handled in this bug tracker. > In #94563#1283448, @ZedDB wrote: > @brecht if it is not supported or stable, then perhaps we should hide the build option as an advanced build flag? The advanced cmake options are currently used mainly for features that only Blender developers would ever enable. I think this should remain easier to discover than that.

Gentoo typically builds everything from source. Some of the options may be hidden internally, but if we are missing things from the gentoo ebuild (package spec) compared to the official blender release, then we should fix that. If I keep having stability issues I may well develop a binary install ebuild, but that is generally frown upon.

Thank you for all the feedback, and thank you again for fixing the minor return value issue.

Gentoo typically builds everything from source. Some of the options may be hidden internally, but if we are missing things from the gentoo ebuild (package spec) compared to the official blender release, then we should fix that. If I keep having stability issues I may well develop a binary install ebuild, but that is generally frown upon. Thank you for all the feedback, and thank you again for fixing the minor return value issue.

Added subscriber: @thesamesam

In #94563#1284030, @brecht wrote:
If you want the most stable/complete Blender build, it's most straightforward to download the build from blender.org instead of building your own. Even with all use flags the gentoo package still misses some things compared to the official release.

In any case, issues specific to the gentoo package are not handled in this bug tracker.

I don't think anything about this bug so far has been Gentoo-specific other than needing to turn off an experimental option (I wasn't aware it was experimental). The .desktop file isn't Gentoo-specific.

Happy to turn it off but given a Blender developer wasn't clear on this, there's probably some change which can be made on the Blender side to clarify the situation too.

> In #94563#1284030, @brecht wrote: > If you want the most stable/complete Blender build, it's most straightforward to download the build from blender.org instead of building your own. Even with all use flags the gentoo package still misses some things compared to the official release. > > In any case, issues specific to the gentoo package are not handled in this bug tracker. > I don't think anything about this bug so far has been Gentoo-specific other than needing to turn off an experimental option (I wasn't aware it was experimental). The .desktop file isn't Gentoo-specific. Happy to turn it off but given a Blender developer wasn't clear on this, there's probably some change which can be made on the Blender side to clarify the situation too.

In #94563#1284113, @thesamesam wrote:
Happy to turn it off but given a Blender developer wasn't clear on this, there's probably some change which can be made on the Blender side to clarify the situation too.

Right, I'm getting mixed signals as well...

@brecht just to clarify, the "cycles standalone" build option is not on per default in Gentoo. The user has to explicitly enable that build option when building and installing Blender via the package manager in Gentoo.
The build options that we use for our standard build (besides CUDA,Optix,OpenCL, and HIP) are on per default. So if the user wants the same options that our regular builds have, they don't have to do anything.
What happened here is that some users enabled non standard (but non advanced) build options and discovered some bugs.

You pointed out that:

It's not stable enough or ready to be installed as part of a Blender package, we do not provide any support for it.

If that is the case, then I feel that the build option is only for developers even if you stated otherwise.
IE if we don't provide any support for it, that means to me that no end user should ever want to build with that flag enabled.
I could understand this if the build option was marked as advanced or if it was clearly indicated that you are on your own if the option was turned on with a CMake warning or something.

None the less even if this is not clarified further in our build system in blender, it is easy enough to remove the option for this in the Gentoo ebuild.
However that means that building cycles standalone will not be an option at all anymore, which means only developers really only have access to the option.
Which is contradictory to what you stated about the option not being for developers only.

> In #94563#1284113, @thesamesam wrote: > Happy to turn it off but given a Blender developer wasn't clear on this, there's probably some change which can be made on the Blender side to clarify the situation too. Right, I'm getting mixed signals as well... @brecht just to clarify, the "cycles standalone" build option is not on per default in Gentoo. The user has to explicitly enable that build option when building and installing Blender via the package manager in Gentoo. The build options that we use for our standard build (besides CUDA,Optix,OpenCL, and HIP) are on per default. So if the user wants the same options that our regular builds have, they don't have to do anything. What happened here is that some users enabled non standard (but non advanced) build options and discovered some bugs. You pointed out that: > It's not stable enough or ready to be installed as part of a Blender package, we do not provide any support for it. If that is the case, then I feel that the build option is only for developers even if you stated otherwise. IE if we don't provide any support for it, that means to me that no end user should ever want to build with that flag enabled. I could understand this if the build option was marked as advanced or if it was clearly indicated that you are on your own if the option was turned on with a CMake warning or something. None the less even if this is not clarified further in our build system in blender, it is easy enough to remove the option for this in the Gentoo ebuild. However that means that building cycles standalone will not be an option at all anymore, which means only developers really only have access to the option. Which is contradictory to what you stated about the option not being for developers only.

BTW, with a name like "standalone" and no explanation I figured that since I am not building with CUDA on my laptop because CUDA no longer supports the dual GPU's in my laptop this would be a standalone build. Sorry I completely misinterpreted the meaning of standalone.

For completeness, I went and make a table based off of the blender_release.cmake provided above, compared with the Gentoo IUSE flags:

IUSE="+bullet +dds +fluid +openexr +system-python +system-numpy +tbb
alembic collada +color-management cuda +cycles
debug doc +embree +ffmpeg +fftw +gmp headless jack jemalloc jpeg2k
man ndof nls openal +oidn +openimageio +openmp +opensubdiv
+openvdb +osl +pdf +potrace +pugixml pulseaudio sdl +sndfile \

      standalone test +tiff valgrind"

Forced off in blender / set in Gentoo:

ASSERT_ABORT        debug
CYCLES_CUBIN_COMPILER  --none -- (only set in Non Apple below)

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 --

Maybe this will only be useful for the Gentoo folks to sort out any important missing build requirements, but it would be nice if anyone would care to look at the list and see if they think any of the missing (marked -- none -- in the Gentoo USE flag column), and let us know.

Thanks again.

BTW, with a name like "standalone" and no explanation I figured that since I am not building with CUDA on my laptop because CUDA no longer supports the dual GPU's in my laptop this would be a standalone build. Sorry I completely misinterpreted the meaning of standalone. For completeness, I went and make a table based off of the blender_release.cmake provided above, compared with the Gentoo IUSE flags: IUSE="+bullet +dds +fluid +openexr +system-python +system-numpy +tbb \ alembic collada +color-management cuda +cycles \ debug doc +embree +ffmpeg +fftw +gmp headless jack jemalloc jpeg2k \ man ndof nls openal +oidn +openimageio +openmp +opensubdiv \ +openvdb +osl +pdf +potrace +pugixml pulseaudio sdl +sndfile \ ``` standalone test +tiff valgrind" ``` Forced off in blender / set in Gentoo: ``` ASSERT_ABORT debug CYCLES_CUBIN_COMPILER --none -- (only set in Non Apple below) ``` 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 -- ``` Maybe this will only be useful for the Gentoo folks to sort out any important missing build requirements, but it would be nice if anyone would care to look at the list and see if they think any of the missing (marked -- none -- in the Gentoo USE flag column), and let us know. Thanks again.

Added subscriber: @sebastian-4

@sebastian-4 Parborg (zeddb) , to clarify -- blender was unstable with the default build argumentson my system. I queried the possible additions and thought that since I am not compiling with CUDA on my laptop I should add standalone. So, adding standalone was one of my actions. After reviewing the blender_release.cmake I will rebuild my system with +ndof +opencl as you have them on by default. I will also note that I am building with the system provided Python-3.9. It is stable with 3.9 correct?

In #94563#1284361, @ZedDB wrote:
Which is contradictory to what you stated about the option not being for developers only.

When I say "Blender developers" I mean developers that are working on Blender, not any developer or technical user that might build Blender or Cycles. What we consider ready to ship and support in the bug tracker is the default/release CMake options. If you make a build with anything else you're on your own already.

> In #94563#1284361, @ZedDB wrote: > Which is contradictory to what you stated about the option not being for developers only. When I say "Blender developers" I mean developers that are working on Blender, not any developer or technical user that might build Blender or Cycles. What we consider ready to ship and support in the bug tracker is the default/release CMake options. If you make a build with anything else you're on your own already.

Anyway, if Blender is unstable for you then it's not clear that anything that has come up here is relevant to that. That can have many causes and the most efficient way to solve that is to directly look at the problem, solving any warnings that come up is unlikely to help with that.

X-KDE-RunOnDiscreteGpu may be deprecated but Blender runs on older distributions where this is not deprecated, and it's harmless to have anyway.
I think the gentoo package should not set WITH_ASSERT_ABORT, WITH_CXX_GUARDEDALLOC, WITH_CYCLES_STANDALONE, WITH_CYCLES_STANDALONE_GUI, WITH_HEADLESS, WITH_MEM_VALGRIND and probably also not WITH_PYTHON_INSTALL, WITH_PYTHON_INSTALL_NUMPY.
Generating doxygen docs in this package makes no sense to me as there is no C/C++ API and this is only relevant to developers that are working on Blender itself.

Anyway, if Blender is unstable for you then it's not clear that anything that has come up here is relevant to that. That can have many causes and the most efficient way to solve that is to directly look at the problem, solving any warnings that come up is unlikely to help with that. * X-KDE-RunOnDiscreteGpu may be deprecated but Blender runs on older distributions where this is not deprecated, and it's harmless to have anyway. * I think the gentoo package should not set `WITH_ASSERT_ABORT`, `WITH_CXX_GUARDEDALLOC`, `WITH_CYCLES_STANDALONE`, `WITH_CYCLES_STANDALONE_GUI`, `WITH_HEADLESS`, `WITH_MEM_VALGRIND` and probably also not `WITH_PYTHON_INSTALL`, `WITH_PYTHON_INSTALL_NUMPY`. * Generating doxygen docs in this package makes no sense to me as there is no C/C++ API and this is only relevant to developers that are working on Blender itself.

I have just rebuilt blender-3.0.0 verifying that the above packages that should not be set are not. If I figure out what the issue was I will report back, but otherwise I hope to consider this closed and continue working.

@brecht Thank you for your answers! I think that is clear enough now, thanks for you time :)

@EBo if you find stability issues with Blender that are not in the official builds, you should report it in the gentoo bug tracker and we can take if from there.

@brecht Thank you for your answers! I think that is clear enough now, thanks for you time :) @EBo if you find stability issues with Blender that are not in the official builds, you should report it in the gentoo bug tracker and we can take if from there.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

blender-3.0.0 compilation error on progress.get_progress() return values #94563