Created attachment 449726 [details] emerge --info Build fails with USE=vc. With USE=-vc the build is successful. [ 15%] Built target kritaundo2 make[2]: Leaving directory '/var/tmp/portage/media-gfx/krita-3.0.1/work/krita-3.0.1_build' make[1]: *** [CMakeFiles/Makefile2:5517: libs/pigment/CMakeFiles/kritapigment.dir/all] Error 2 make[1]: Leaving directory '/var/tmp/portage/media-gfx/krita-3.0.1/work/krita-3.0.1_build' make: *** [Makefile:128: all] Error 2
Please attach a complete build.log where the problem can be seen.
Created attachment 449852 [details] build.log.gz
Which version of dev-libs/vc is installed?
latest 1.2.0
@amadio, any idea about this VC-related build failure?
Same thing here with VC v1.3.0
Same issue here. Build fails with VC 1.3 But it succeeds with VC 0.7.3 Apparently Krita works only with VC 0.7.x In this bug report https://bugs.kde.org/show_bug.cgi?id=360773 Boudewijn Rempt (A Krita contributor) says: "I'm sorry, but at the moment, only Vc 0.7 is supported. We're looking into porting to a newer version of Vc, but that's not done yet, so this build error is expected." Also the build instructions page referred to on Krita's website http://www.davidrevoy.com/article193/guide-building-krita-on-linux-for-cats David REVOY (The writer of the instructions) says: "@NETHead : Oh ! good job ! Too bad to see again the library issue with Krita using an old specific VC version :-/ Thank you for the fast build script and the solution !" In the current Krita 3.0.1 ebuild vc? ( >=dev-libs/vc-1.1.0 ) changing it to use 0.7.3 vc? ( =dev-libs/vc-0.7.3 ) in a local overlay is a work around that worked for me. Also dev-libs/vc-0.7.3 is not masked, while >=dev-libs/vc-0.7.4 are still masked right now.
An old vc simply results in krita 3 being built without vc, so that's not really a solution. The real solution to this issue is actually right there in the compiler-output on the last line of every error: /usr/include/Vc/avx/intrinsics.h:646:1: error: 'R Vc_1::AvxIntrinsics::stream_load(const float*) [with R = __vector(8) float]' conflicts with a previous declaration } ^ /usr/include/Vc/avx/intrinsics.h:638:75: note: previous declaration 'R Vc_1::AvxIntrinsics::stream_load(const float*) [with R = __vector(4) float]' template<> Vc_INTRINSIC m128 stream_load<m128>(const float *mem) ^ /usr/include/Vc/avx/intrinsics.h:642:75: note: -fabi-version=6 (or =0) avoids this error with a change in mangling template<> Vc_INTRINSIC m256 stream_load<m256>(const float *mem) Krita (and probably everything else that compiles against vc) requires a newer C++-ABI. Add "-fabi-version=0" (or 6+, gcc 4.9 goes up to 8) to CXXFLAGS for krita, and it compiles. Globally changing the C++-ABI is not a good idea.
(In reply to Laurence v/d Elshout from comment #8) > Krita (and probably everything else that compiles against vc) requires a > newer C++-ABI. Add "-fabi-version=0" (or 6+, gcc 4.9 goes up to 8) to > CXXFLAGS for krita, and it compiles. Globally changing the C++-ABI is not a > good idea. There's been some concern raised about fiddling with the ABI. An alternative solution could be to require GCC 5 to be active when USE="vc" is enabled.
(In reply to Michael Palimaka (kensington) from comment #5) > @amadio, any idea about this VC-related build failure? Sorry, I missed this bug before. Compiling against Vc requires the newer C++ ABI, so the solutions have already been found: either add -fabi-version=0, or require >=sys-devel/gcc-5 to be the active compiler. However, is this still an issue? I found the following in the CMakeLists.txt for krita-3.1.2.1 (only version in the tree now): if(Vc_COMPILER_IS_CLANG) set(ADDITIONAL_VC_FLAGS "-Wabi -ffp-contract=fast -fPIC") elseif (NOT MSVC) set(ADDITIONAL_VC_FLAGS "-Wabi -fabi-version=0 -ffp-contract=fast -fPIC") endif() That should take care of the issue, so I'm closing this bug.
Created attachment 462360 [details] krita-3.1.2-r1: build.log.gz Please reopen the bug, the build still fails for me. media-gfx/krita-3.1.2-r1 sys-devel/gcc-4.9.4 dev-libs/vc-1.3.0
(In reply to Guilherme Amadio from comment #10) > if(Vc_COMPILER_IS_CLANG) > set(ADDITIONAL_VC_FLAGS "-Wabi -ffp-contract=fast -fPIC") > elseif (NOT MSVC) > set(ADDITIONAL_VC_FLAGS "-Wabi -fabi-version=0 -ffp-contract=fast > -fPIC") > endif() > > That should take care of the issue, so I'm closing this bug. Note that neither ADDITIONAL_VC_FLAGS nor ko_compile_for_all_implementations{,_no_scalar} macros aren't used in the cmake files any place after their definitions. So this snip of code either broken or piece of not finished functionality... PS: I can confirm that passing "-fabi-version=0" to C[XX]FLAGS workarounds the issue.
(In reply to Fat-Zer from comment #12) > (In reply to Guilherme Amadio from comment #10) > > if(Vc_COMPILER_IS_CLANG) > > set(ADDITIONAL_VC_FLAGS "-Wabi -ffp-contract=fast -fPIC") > > elseif (NOT MSVC) > > set(ADDITIONAL_VC_FLAGS "-Wabi -fabi-version=0 -ffp-contract=fast > > -fPIC") > > endif() > > > > That should take care of the issue, so I'm closing this bug. > > Note that neither ADDITIONAL_VC_FLAGS nor > ko_compile_for_all_implementations{,_no_scalar} macros aren't used in the > cmake files any place after their definitions. So this snip of code either > broken or piece of not finished functionality... > > PS: I can confirm that passing "-fabi-version=0" to C[XX]FLAGS workarounds > the issue. You are right. I applied a patch that uses add_compile_options(), which fixes this now: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8c3ad9a5535e0c3d5c90c5bfd31511d33a2fffb1
