Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build issues on Ubuntu 24.04 - incorrect openmp linkage in CMake #959

Open
dbabokin opened this issue Aug 29, 2024 · 3 comments · May be fixed by #984
Open

Build issues on Ubuntu 24.04 - incorrect openmp linkage in CMake #959

dbabokin opened this issue Aug 29, 2024 · 3 comments · May be fixed by #984

Comments

@dbabokin
Copy link

OpenMP libraries a linked using the library name (i.e. omp):

if (OPENMP_FOUND)
target_compile_options(xsmm_dnn_mlp PRIVATE ${OpenMP_C_FLAGS})
target_link_libraries(xsmm_dnn_mlp PRIVATE omp)
endif()

if(USE_OpenMP)
set(OPENMP_LIBS_INCL "-lomp")
endif()

This is not portable, as it assumes the libomp.so is in standard location, which might not be the case. And it seems that what happens on Ubuntu 24.04 with libomp-dev package installed. -lomp5 works, but not -lomp.

The recommended way to handle this is the following:

target_link_libraries(xsmm_dnn_mlp PRIVATE OpenMP::OpenMP_C)

And that fix perfectly fixes the first code snippet.

For the second case it's a bit messy, because of --no-as-needed/--as-needed hack. I suggest using OpenMP_C_LIBRARIES instead of -lomp, though it brings two libraries on my machine: /usr/lib/llvm-18/lib/libomp.so;/lib/aarch64-linux-gnu/libpthread.a

@rengolin
Copy link
Contributor

rengolin commented Oct 11, 2024

Coming back to this, I did some digging, and it's not clear to me how to set an actual vendor.

Here's some background information: https://stackoverflow.com/questions/46414660/macos-cmake-and-openmp#48216682

I tried:

  # Force LLVM version of OpenMP
  set(OpenMP_C_LIB_NAMES "omp")
  set(OpenMP_CXX_LIB_NAMES "omp")
  set(OpenMP_omp_LIBRARY ${OpenMP_C_LIB_NAMES})
  set(OpenMP_libomp_LIBRARY ${OpenMP_C_LIB_NAMES})
  set(OpenMP_libgomp_LIBRARY ${OpenMP_C_LIB_NAMES})
  find_package(OpenMP REQUIRED)

Which Clang gets it:

-- Found OpenMP_C: -fopenmp=libomp (found version "5.0") 
-- Found OpenMP_CXX: -fopenmp=libomp (found version "5.0") 

and links correctly.

But GCC still doesn't:

-- Found OpenMP_C: -fopenmp (found version "4.5") 
-- Found OpenMP_CXX: -fopenmp (found version "4.5") 

And emits:

ld.lld: error: unable to find library -lomp

@rengolin
Copy link
Contributor

rengolin commented Oct 11, 2024

And it seems that what happens on Ubuntu 24.04 with libomp-dev package installed. -lomp5 works, but not -lomp.

Weird, my build machine runs on Ubuntu 22.04.5 and does not have that problem. We run on Intel, AMD and Arm machines from AWS and did not have that problem either.

The recommended way to handle this is the following:

target_link_libraries(xsmm_dnn_mlp PRIVATE OpenMP::OpenMP_C)

And that fix perfectly fixes the first code snippet.

Not quite. This doesn't fix the issue, just makes GCC chose GOMP instead of OMP, which compiles and links fine, but the execution is really slow on high core count.

Our rationale behind forcing LLVM's OMP is performance. You must install libomp into your system (packages, make install, etc) and CMake must be able to find it. Each distro is different, so adding special rules here misses the point of using CMake in the first place.

I suggest using OpenMP_C_LIBRARIES instead of -lomp, though it brings two libraries on my machine: /usr/lib/llvm-18/lib/libomp.so;/lib/aarch64-linux-gnu/libpthread.a

I agree here. We probably got away with it because libpthread.a is already included elsewhere. But we still need to make sure LLVM's OMP is selected, otherwise, we'd just link GOMP here and not compare apples to apples on benchmarking.

@dbabokin
Copy link
Author

Reading CMake sources I don't see a way to specify a vendor. We should probably ping CMake maintainer on https://gitlab.kitware.com/cmake/cmake/-/issues/26263 and live with a hack in the meantime.

@rengolin rengolin linked a pull request Nov 21, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants