Created attachment 757869 [details] build log Bug 798789 was closed without any apparent resolution.
(In reply to Luke-Jr from comment #0) > Created attachment 757869 [details] > build log > > Bug 798789 was closed without any apparent resolution. Yeah, they didn't ever upload any logs and closed it themselves.
Anyway, please try 3.13.2 & add emerge --info here.
https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/embree/embree-3.13.2.ebuild#n57
Adding a bunch more filters for -msse2* and stuff I guess is what's needed.
ETA on when 3.13.2 released into the main tree?
(In reply to John (EBo) David from comment #5) > ETA on when 3.13.2 released into the main tree? It's already in tree, just not marked stable yet.
Created attachment 757871 [details] 3.13.2 build log Same failure with 3.13.2
Created attachment 757872 [details] emerge --info
I guess we can add all "-m*" flags to "filter-flags". Otherwise we will compile embree modules with optimization flags that they should not have. Perhaps we should even remove all of the CPU_FLAGS as settings as well because some programs expect all supported instruction modules to be present. Embree will load the correct module at runtime, so the only thing we would give up is some extra space and compile time.
@mgorny I don't know if you are the correct person to get feedback, so I'm sorry if I dragged you into this when I shouldn't. So the issue is (as far as I can tell) that the embree build system is specifically constructed to build different modules that can be loaded on the fly depending on the CPU of the host machine. It is possible to disable some of these modules, but there is no "build a module that will only work on this build computer". So if you pass custom compile flags to the build system it has a very high chance of failing to build if it is not very simple flags like setting the optimization level ("-O2") or building with debug symbols. So I'm wondering what you think the path forward here is. To me it would seem logical to simply just disable any custom compile flags so we ship something that is supported by upstream. We could of course also simply filter out nearly all compile flags that we know will break the build, but at this point, I don't know if it is worth doing?
I can confirm this. I made a workaround with commenting out the line "-DEMBREE_IGNORE_CMAKE_CXX_FLAGS=OFF" or switching this to ON. I had also tried setting the use flag setting variants of CXXFLAGS="-DEMBREE_IGNORE_CMAKE_CXX_FLAGS=ON" but was never able to get that work. I can deposit my own emerge --info, and both the failing and successful logs if that would help, but I am not sure if that would be helpful at this point. As a note, I could also try adding a custom user defined use flag to switch EMBREE_IGNORE_CMAKE_CXX_FLAGS ON/OFF appropriately, so that I can set it in packge.use, but before I spend the time to do that and test it I wanted to also ask if anyone has a suggestion on how to instantiate the EMBREE_IGNORE_CMAKE_CXX_FLAGS value in package.use. That might be the simplist fix if there is a way.
(In reply to Sebastian Parborg from comment #9) > I guess we can add all "-m*" flags to "filter-flags". > Otherwise we will compile embree modules with optimization flags that they > should not have. > We should do this and have USE=custom-cflags with a description in metadata.xml. (In reply to John (EBo) David from comment #11) > I can confirm this. I made a workaround with commenting out the line > "-DEMBREE_IGNORE_CMAKE_CXX_FLAGS=OFF" or switching this to ON. I had also > tried setting the use flag setting variants of > CXXFLAGS="-DEMBREE_IGNORE_CMAKE_CXX_FLAGS=ON" but was never able to get that > work. I can deposit my own emerge --info, and both the failing and > successful logs if that would help, but I am not sure if that would be > helpful at this point. > > As a note, I could also try adding a custom user defined use flag to switch > EMBREE_IGNORE_CMAKE_CXX_FLAGS ON/OFF appropriately, so that I can set it in > packge.use, but before I spend the time to do that and test it I wanted to > also ask if anyone has a suggestion on how to instantiate the > EMBREE_IGNORE_CMAKE_CXX_FLAGS value in package.use. That might be the > simplist fix if there is a way. In mycmakeargs in the ebuild, e.g -DEMBREE_IGNORE_CMAKE_CXX_FLAGS=$(usex custom-cflags)
IMO, what would make the most sense, is simply filtering out the contradicting flag for the one file that requires it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2bfff0fd6e8711c40e1faf3e203a79b24c1e0e76 commit 2bfff0fd6e8711c40e1faf3e203a79b24c1e0e76 Author: Sebastian Parborg <darkdefende@gmail.com> AuthorDate: 2022-02-17 19:00:21 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-02-18 02:37:12 +0000 media-libs/embree: Filter out more compile flags Embree will fail building if we pass CPU specific useflags. This is because Embree builds multiple modules so it can autodetect the CPU instruction set to use at runtime. Closes: https://bugs.gentoo.org/828659 Signed-off-by: Sebastian Parborg <darkdefende@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> media-libs/embree/embree-3.13.0-r2.ebuild | 6 +++--- media-libs/embree/embree-3.13.2.ebuild | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-)
