submit_kernel(): omp_queue: Could not find required kernel launcher

[garymm]

I believe I managed to build OpenSYCL in library only mode targeting OpenMP with the commands:

mkdir -p build
cd build
cmake -DWITH_CUDA_BACKEND=OFF \
   -DWITH_ACCELERATED_CPU=OFF \
   -DWITH_SSCP_COMPILER=OFF \
   -DCMAKE_INSTALL_PREFIX=$(pwd)/install  ../
make -j$(nproc --all) install

Now I've compiled my binary using my regular toolchain, not syclcc (as I believe should be possible in library-only mode).
I can compile a binary that uses the produced libraries, but at run-time it fails with:

[hipSYCL Error] from /home/garymm/src/OpenSYCL/OpenSYCL/include/hipSYCL/runtime/omp/../kernel_launcher.hpp:136 @ find_launcher(): No kernel launcher is present for requested backend
[hipSYCL Error] from /home/garymm/src/OpenSYCL/OpenSYCL/src/runtime/omp/omp_queue.cpp:304 @ submit_kernel(): omp_queue: Could not find required kernel launcher

I tried linking my binary against libgomp.so.1 as well, and that didn't seem to make any difference.

Any tips on what might be going wrong?
Thanks!

[illuhad]

syclcc should also be used in library-only mode. While it is in principle possible to compile SYCL code manually without syclcc in the library-only case, syclcc adds a couple of flags to the compiler invocation that are not necessarily intuitive, or require knowledge of Open SYCL header internals:

• Setting some macro definitions that configure the SYCL headers, and, in particular enable the required backends.
• Automatically set include paths appropriately
• Automatically link against the SYCL runtime library using rpath if possible.

If you want to see the compiler invocation with all the flags that it actually invokes, you can use --opensycl-dryrun.

The particular error you are getting is most likely because if the required macro to enable the OpenMP backend is not set, no kernel is actually generated, and then there's nothing that can be invoked at runtime.

So tl;dr: syclcc is a generic driver to handle all our compilation flows under a unified roof. While it does not add SYCL-specific compiler logic in the library-only case (and indeed you can tell it to use an arbitrary CPU compiler using --opensycl-cpu-cxx=...) it does set some flags that require in-depth knowledge of the implementation, and should therefore be considered implementation details.

[illuhad]

I have to pass it a source file as an additional argument to get it spit out the compiler flags. Should I file a bug about that, or is that intended? It's kind of surprising.

This is expected. Different flags may be needed when only linking or compiling as well, so syclcc has to react accordingly. --opensycl-dryrun tells you what exactly is going to be invoked for the current invocation, so if you run syclcc --opensycl-dryrun test.cpp it will recognize this as a compile command and print the compilation command. If there's no source file involved it assumes that you are only linking.

I tried running syclcc directly and it works, though it does print a warning that is somewhat concerning:

That one I'm not 100% sure about, but it might be related to syclcc only linking with rpath by default if the CPU compiler is clang because rpath works differently for different compilers, and we cannot add handling for the quirks of every conceivable compiler. The application should still run; in the worst case you might have to set LD_LIBRARY_PATH.

[garymm]

If there's no source file involved it assumes that you are only linking.

Without arguments what does it link?

[illuhad]

It does not link. It currently assumes that we are in the "pure linkage" flow if no source files are present. If no object files to be linked are present either, it still prints the flags for the pure linkage flow.

[garymm]

That's pretty confusing from my point of view.

[illuhad]

Maybe. But it's not a high priority item. --opensycl-dryrun is intended for debugging and introspecting the syclcc behavior for a given compilation command line, not for documenting flags (for this purpose, look at syclcc.json in etc).
The compiler invocation without any file argument would lead to a compiler error without --opensycl-dryrun, so it's an invalid case where the syclcc behavior normally does not matter.

[garadeaniket]

[illuhad]

The problem was that syclcc/acpp were not used to compile the application. These tools set some internal preprocessor macro to correctly configure code paths in the headers. Therefore, they are required even in library-only mode.

[garadeaniket]

[illuhad]

See e.g. acpp --acpp-dryrun --acpp-targets=omp somefile.cpp