This is a different workaround shared the same issue with [603546](https://bugs.gentoo.org/603546). For llvm/clang openmp support, OpenMP is provided by libomp. The compile execution calls: $(tc-getCC "$@") -fopenmp "${base}.c" -o "${base}" >&/dev/null when CC=clang may failed while the linker is default to gnu-ld, and uses the openmp library to build. A good practice maybe $(tc-getCC "$@") ${LDFLAGS} -fopenmp "${base}.c" -o "${base}" >&/dev/null From the documentation of [Clang](https://wiki.gentoo.org/wiki/Clang), we usually set the proper LDFLAGS when using Clang as toolchain, therefore it is recommended to add these flags to the compile command line as it will not break the test for users using gcc.
(In reply to Gamcheong Yuen from comment #0) > This is a different workaround shared the same issue with > [603546](https://bugs.gentoo.org/603546). > > For llvm/clang openmp support, OpenMP is provided by libomp. The compile > execution calls: > > $(tc-getCC "$@") -fopenmp "${base}.c" -o "${base}" >&/dev/null > > when CC=clang may failed while the linker is default to gnu-ld, and uses the > openmp library to build. A good practice maybe > > $(tc-getCC "$@") ${LDFLAGS} -fopenmp "${base}.c" -o "${base}" >&/dev/null I'm not sure about that. We don't use ${CFLAGS} either. Do you have actual failure example? I would expect compiler driver to always add according library. $ cat a.c #include <omp.h> int main() { int nthreads, tid, ret = 0; #pragma omp parallel private(nthreads, tid) { tid = omp_get_thread_num(); nthreads = omp_get_num_threads(); ret += tid + nthreads; } return ret; } $ gcc a.c -o a -fopenmp $ gcc a.c -o a -fopenmp -fuse-ld=gold $ gcc a.c -o a -fopenmp -fuse-ld=lld $ clang a.c -o a -fopenmp $ clang a.c -o a -fopenmp -fuse-ld=gold $ clang a.c -o a -fopenmp -fuse-ld=lld All of them do work. Or your extra CFLAGS/LDFLAGS actually break openmp support? > From the documentation of [Clang](https://wiki.gentoo.org/wiki/Clang), we > usually set the proper LDFLAGS when using Clang as toolchain, therefore it > is recommended to add these flags to the compile command line as it will not > break the test for users using gcc. The page says nothing about openmp. What should "proper LDFLAGS" mean in context of openmp?
Though it is just a test section, I think we may keep the consistency of the whole merge process that use the same FLAGS to build. The situation was that I have changed the toolchain according to the documentation [Clang](https://wiki.gentoo.org/wiki/Clang) and LLVM OMP has been already installed. But what break the test was I did not USE `default-lld` when installing Clang (due to the docs), and it seems that Clang told the linker to find libomp in a relative path to LLVM and ld thought it not found. I was tried to simply build the test program without portage, the error info told me that libomp cannot be found, and the search path looked like a relative path to the LLVM installation directory. By just adding "-fuse-ld=lld" to clang it will compile the program. Actually I cannot figure out the internal reason of this problem that $ clang a.c -o a -fopenmp do not compile the program. And what I can provide is I am using Clang-12, and I did the default installation steps. Along the installation steps, I was set LDFLAGS="-fuse-ld=lld -rtlib=compiler-rt -unwindlib=libunwind" as the document describes.
(In reply to Gamcheong Yuen from comment #2) > Though it is just a test section, I think we may keep the consistency of the > whole merge process that use the same FLAGS to build. > > The situation was that I have changed the toolchain according to the > documentation [Clang](https://wiki.gentoo.org/wiki/Clang) and LLVM OMP has > been already installed. But what break the test was I did not USE > `default-lld` when installing Clang (due to the docs), and it seems that > Clang told the linker to find libomp in a relative path to LLVM and ld > thought it not found. > > I was tried to simply build the test program without portage, the error info > told me that libomp cannot be found, and the search path looked like a > relative path to the LLVM installation directory. By just adding > "-fuse-ld=lld" to clang it will compile the program. > > Actually I cannot figure out the internal reason of this problem that > > $ clang a.c -o a -fopenmp > > do not compile the program. And what I can provide is I am using Clang-12, > and I did the default installation steps. Along the installation steps, I > was set > > LDFLAGS="-fuse-ld=lld -rtlib=compiler-rt -unwindlib=libunwind" > > as the document describes. Later I reinstalled Clang USing `default-lld` and got rid of the problem.
(In reply to Gamcheong Yuen from comment #2) > Though it is just a test section, I think we may keep the consistency of the > whole merge process that use the same FLAGS to build. > > The situation was that I have changed the toolchain according to the > documentation [Clang](https://wiki.gentoo.org/wiki/Clang) and LLVM OMP has > been already installed. But what break the test was I did not USE > `default-lld` when installing Clang (due to the docs), and it seems that > Clang told the linker to find libomp in a relative path to LLVM and ld > thought it not found. > > I was tried to simply build the test program without portage, the error info > told me that libomp cannot be found, and the search path looked like a > relative path to the LLVM installation directory. By just adding > "-fuse-ld=lld" to clang it will compile the program. > > Actually I cannot figure out the internal reason of this problem that > > $ clang a.c -o a -fopenmp > > do not compile the program. Can you post the output how it fails for you? It's not clear if it still fails for you or not. > And what I can provide is I am using Clang-12, > and I did the default installation steps. Along the installation steps, I > was set > > LDFLAGS="-fuse-ld=lld -rtlib=compiler-rt -unwindlib=libunwind" > > as the document describes.
I figured this out. Clang requires building with `-lm` to provide the following functions: logbl() fmaxl() Fix: $(tc-getCC "$@") -fopenmp -lm "${base}.c" -o "${base}" >&/dev/null in: toolchain-funcs.eclass Function: tc-has-openmp() When trying to compile the following code using Clang without `-lm`: #include <omp.h> int main() { int nthreads, tid, ret = 0; #pragma omp parallel private(nthreads, tid) { tid = omp_get_thread_num(); nthreads = omp_get_num_threads(); ret += tid + nthreads; } return ret; } I get: libomp.so: undefined reference to fmaxl libomp.so: undefined reference to logbl Adding -lm will work for GCC as well, even though it's not needed (may save some LOC in the eclass FWIW)
This isn't quite right, no? The issue is that libomp is underlinked. There shouldn't be a need to adjust for that in the eclass. *** This bug has been marked as a duplicate of bug 816831 ***
