Created attachment 743790 [details] build.log libomp uses the fmaxl function from libm, but does not link against it unless if on BSD - gcc provides many of these functions as builtins (see https://stackoverflow.com/questions/45485060/why-does-clang-require-lm-unlike-gcc ), clang doesn't. the Cmake config should probably just link against libm if building with clang? This happens with 12, 13, and potentially older versions too. Output from nm -D image/usr/lib64/libomp.so | grep fmaxl U fmaxl Output from readelf -d image/usr/lib64/libomp.so | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [librt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] Attached is the build.log cheers to Arfrever for quickly finding the cause.
https://bugs.llvm.org/show_bug.cgi?id=52115
*** Bug 665474 has been marked as a duplicate of this bug. ***
See https://bugs.gentoo.org/665474#c0 too.
*** Bug 794481 has been marked as a duplicate of this bug. ***
Sam James, thank you for marking that bug I commented on as a duplicate. I see what the real problem is now. You're right, -lm shouldn't be needed for the eclass. As for now, what do you suggest until this is properly fixed? Does this bug actually break anything aside from causing tc-has-openmp() to fail?
I passed `-lm` to LDFLAGS specific for sys-libs/libomp and this fixed it. `readelf` and `nm` confirms.
*** Bug 851597 has been marked as a duplicate of this bug. ***
This will be fixed in LLVM 15, but we may backport it sooner: https://github.com/llvm/llvm-project/commit/2d0c9b64a07c6c430ccfe11ea4c767d788d20461. Thanks to telans and maskray.
This is in at least 14.0.6 in Gentoo.