Using MKL::MKL to resolve the -fsycl issue with AdaptiveCpp fails.

[lrpablo]

Summary

Trying to link the examples when compiling with AdaptiveCpp using MKL::MKL as the target library fails.

Version

oneMKL version 0.2.0
githash = f4d6b19.

Environment

• OS name and version=Ubuntu 22.04.4 LTS

• Compiler version=AdaptiveCpp version: 24.02.1+git.d1341108.20240718.branch.develop.dirty

• CMake output log
  -- CMAKE_BUILD_TYPE: None, set to Release by default
  -- The CXX compiler identification is Clang 18.1.8
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: /home/pablo/usr/local/bin/acpp - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- TARGET_DOMAINS: blas
  -- MKL_VERSION: 2025.0.0
  -- MKL_ROOT: /opt/intel/oneapi/mkl/2025.0
  -- MKL_SYCL_ARCH: intel64
  -- MKL_ARCH: intel64
  -- MKL_SYCL_LINK: dynamic
  -- MKL_LINK: dynamic
  -- MKL_SYCL_INTERFACE_FULL: intel_ilp64
  -- MKL_INTERFACE_FULL: intel_ilp64
  -- MKL_SYCL_THREADING: tbb_thread
  -- MKL_THREADING: tbb_thread
  -- MKL_MPI: None, set to intelmpi by default
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_scalapack_ilp64.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_cdft_core.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_intel_ilp64.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_tbb_thread.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_core.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_blacs_intelmpi_ilp64.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_sycl_blas.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_sycl_lapack.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_sycl_dft.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_sycl_sparse.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_sycl_data_fitting.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_sycl_rng.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_sycl_stats.so
  -- Found /opt/intel/oneapi/mkl/2025.0/lib/libmkl_sycl_vm.so
  -- Looking for hipSYCL
  CMake Deprecation Warning at /home/pablo/usr/local/lib/cmake/hipSYCL/hipsycl-config.cmake:27 (message):
  find_package(hipSYCL) is deprecated. Use find_package(AdaptiveCpp)
  instead. For this, you may have to set
  -DAdaptiveCpp_DIR=/install/prefix/lib/cmake/AdaptiveCpp. Additionally,
  replace -DHIPSYCL_* cmake arguments with -DACPP_*
  Call Stack (most recent call first):
  CMakeLists.txt:279 (find_package)

CMake Warning (dev) at cmake/FindcuBLAS.cmake:20 (find_package):
Policy CMP0146 is not set: The FindCUDA module is removed. Run "cmake
--help-policy CMP0146" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.

Call Stack (most recent call first):
src/blas/backends/cublas/CMakeLists.txt:22 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found CUDA: /usr/local/cuda (found suitable version "12.5", minimum required is "10.0")
-- Found cuBLAS: /usr/local/cuda/include
-- ONEAPI_DEVICE_SELECTOR will be set to the following value(s): [opencl:cpu;cuda:gpu] for run-time dispatching examples
-- Configuring done (0.7s)
-- Generating done (0.0s)
-- Build files have been written to: oneMKL/build

Steps to reproduce

Edit the file src/blas/backends/mklcpu/CMakeLists.txt

44c44,48
<   target_link_libraries(${LIB_OBJ} PUBLIC ONEMKL::SYCL::SYCL MKL::MKL_SYCL::BLAS)
---
>   if(ONEMKL_SYCL_IMPLEMENTATION STREQUAL "hipsycl")
>     target_link_libraries(${LIB_OBJ} PUBLIC ONEMKL::SYCL::SYCL MKL::MKL)
>   else()
>     target_link_libraries(${LIB_OBJ} PUBLIC ONEMKL::SYCL::SYCL MKL::MKL_SYCL::BLAS)
>   endif()

  cmake .. -DONEMKL_SYCL_IMPLEMENTATION=hipSYCL \
       -DhipSYCL_DIR=/home/pablo/usr/local/lib/cmake/hipSYCL \
       -DCMAKE_CXX_COMPILER=/home/pablo/usr/local/bin/acpp \
       -DENABLE_MKLGPU_BACKEND=False \
       -DENABLE_MKLCPU_BACKEND=True \
       -DENABLE_CUBLAS_BACKEND=True \
       -DENABLE_CURAND_BACKEND=True \
       -DBUILD_FUNCTIONAL_TESTS=False \
      -DBUILD_EXAMPLES=True \
      -DTARGET_DOMAINS="blas" \
      -DHIPSYCL_TARGETS=cuda:sm_75

Observed behavior

When using MKL::MKL as the target library in src/blas/backends/mklcpu/CMakeLists.txt, the issue with attempting to compile the examples with the -fsycl switch is resolved, but errors occurs when trying to link.

[ 90%] Linking CXX executable ../../../../bin/example_blas_gemm_usm_mklcpu_cublas
/usr/bin/ld: ../../../../lib/libonemkl_blas_mklcpu.so.0: undefined reference to `oneapi::mkl::blas::row_major::omatcopy(hipsycl::sycl::queue&, oneapi::mkl::transpose, long, long, std::complex<float>, hipsycl::sycl::buffer<std::complex<float>, 1, std::allocator<std::complex<float> > >&, long, hipsycl::sycl::buffer<std::complex<float>, 1, std::allocator<std::complex<float> > >&, long)'
...
...
...
/usr/bin/ld: ../../../../lib/libonemkl_blas_mklcpu.so.0: undefined reference to `oneapi::mkl::blas::column_major::trsm(hipsycl::sycl::queue&, oneapi::mkl::side, oneapi::mkl::uplo, oneapi::mkl::transpose, oneapi::mkl::diag, long, long, oneapi::mkl::value_or_pointer<float>, float const*, long, float*, long, std::vector<hipsycl::sycl::event, std::allocator<hipsycl::sycl::event> > const&)'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [examples/blas/compile_time_dispatching/level3/CMakeFiles/example_blas_gemm_usm_mklcpu_cublas.dir/build.make:105: bin/example_blas_gemm_usm_mklcpu_cublas] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:497: examples/blas/compile_time_dispatching/level3/CMakeFiles/example_blas_gemm_usm_mklcpu_cublas.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2

[Rbiessy]

Note that the issue with AdaptiveCpp is a duplicate of #478

The issue of undefined reference with the MKLCPU backend is surprising. It looks like you are trying a 2025.0 RC which we don't have access to. Do you know if this also fails with 2024.2?

[lrpablo]

Yes, it also fails with version 2024.2. And yes, it's related to issue #478, as the goal is to remove the attempt to compile with -fsycl, but in doing so, a new error occurs: the linking problem.