Summary: | media-libs/opencv lto-wrapper: fatal error | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Austin Kilgore <kilgorephotoshop> |
Component: | Current packages | Assignee: | Paul Zander <negril.nx+gentoo> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | fatzer2, fordfrog, ionen, kfirufk, proxy-maint, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
build-2.log |
Description
Austin Kilgore
2021-08-30 21:31:49 UTC
Created attachment 736843 [details]
build.log
-lpthread -L/usr/lib64 -Wl,-rpath-link,"\$ORIGIN" && : {standard input}: Assembler messages: {standard input}:341978: Error: symbol `fatbinData' is already defined lto-wrapper: fatal error: /usr/bin/x86_64-pc-linux-gnu-g++ returned 1 exit status compilation terminated. /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status [119/1141] /usr/bin/x86_64-pc-linux-gnu-g++ -DCVAP It does look vaguely a bit like it could still be happening when OOMing. I did say to stop using -j16 :( This is still an issue and it's not OOMing, I've watched my ram usage and it doesn't even build enough of the way into it for it to be running out of ram. Created attachment 737050 [details]
build-2.log
Note that the build failure is probably triggered by USE="cuda" (In reply to Fat-Zer from comment #5) > Note that the build failure is probably triggered by USE="cuda" Yes, just happened to try to build this and ran into the same fatbindata/lto-wrapper error with USE="cuda lto" Fine I USE=-cuda, but haven't looked into this further. Seems to be a somewhat well-established CUDA + LTO incompatibility? https://forums.developer.nvidia.com/t/link-time-optimization-with-cuda-on-linux-flto/55530/6. Seems like we should just make them mutually exclusive (or just filter it, which is probably nicer). (In reply to Sam James from comment #7) > Seems to be a somewhat well-established CUDA + LTO incompatibility? > https://forums.developer.nvidia.com/t/link-time-optimization-with-cuda-on- > linux-flto/55530/6. > > Seems like we should just make them mutually exclusive (or just filter it, > which is probably nicer). Oh you're right, came across this before but forgot about it. Can't even compile a hello.cu with nvcc -Xcompiler -flto fwiw if wanted to limit this only to nvcc, could add something like: $(multilib_native_usex cuda -DCUDA_NVCC_FLAGS="-Xcompiler;-fno-lto" '') Built fine with USE="cuda lto" with that. Not that this all feels particularly right when comparing to opensubdiv (cuda eclass, nvccflags, arch selection -- would need to inspect OpenCVDetectCuda.cmake to stop it from appending arches). Unfortunately my own interest in improving cuda stuff been low, I barely use/know any of these packages. hey everyone, somehow adding following line, fixes the issue: $(multilib_native_usex cuda -DCUDA_NVCC_FLAGS="-dlto" '') maybe even this one, since it is just an alias to '-dlto': $(multilib_native_usex cuda -DCUDA_NVCC_FLAGS="-lto" '') of course I do not have any idea if that is correct, but hey! it compiles, even the "hello.cu" with it. tested on media-libs/opencv-4.6.0-r1. *** Bug 913918 has been marked as a duplicate of this bug. *** with cuda-12, nvcc is failing, for the -dlto option nvcc says that there is also need to specify -code (and/or) -arch, so I assume for my setup should work sthg like $(multilib_native_usex cuda -DCUDA_NVCC_FLAGS=-dlto '') ?($(multilib_native_usex cuda -DCUDA_NVCC_FLAGS=-code=lto_89 '')) $(multilib_native_usex cuda -DCUDA_NVCC_FLAGS=-arch=lto_89 '') (cause having arch sm_89) will try after moving through https://bugs.gentoo.org/915775 I set MYCMAKEARGS="-DCUDA_GENERATION=Lovelace -DOpenGL_GL_PREFERENCE=GLVND" for opencv that doesn't allow for lto though. The code at https://github.com/opencv/opencv/blob/4.x/cmake/OpenCVDetectCUDA.cmake#L257C10-L257 might interfere with your plans. But outside the extra ?( ) it looks fine. As per nvcc --help you might not need -dlto. |