[Openmp-dev] [RFC] Clarify the absence of API stability for the *device runtime* (aka. libomptarget-nvptx-sm_XX.bc)

[Michael Kruse via Openmp-dev]

Am Do., 9. Juli 2020 um 14:08 Uhr schrieb Hal Finkel <hfinkel at anl.gov>:
> Also, if we wanted to change clang so that it linked version-locked
> versions of these libraries, -lomptarget-11 or whatever, that, in my
> opinion, would also be a reasonable choice to discuss.
>
> One thing worth capturing is the extent to which these things are
> connected. There is a relationship between libomptarget and its plugins,
> and the plugins and the device-side runtimes. There is an ABI boundary
> there somewhere. If we change nothing else, we might need to consider
> ABI stability of this part of the device-side interface.

The official distribution apt.llvm.org contains libomptarget.so for
LLVM 7 to 10, but each into separate directories under
/usr/lib/llvm-<version>/libomptarget.so. The prebuilt binaries under
https://releases.llvm.org/download.html puts it directly under
<prefix>/libomptarget.so. If libomptarget is version-locked, users
need to be careful about pointing to the right LD_LIBRARY_PATH.
However, I could not find target device plugins in the distributions
(such as lib/libomptarget-nvptx-sm_60.bc when built on a machine with
CUDA). The official ubuntu repository doesn't contain libomptarget at
all. Arch Linux contains at least the x86_64 rtl
(https://www.archlinux.org/packages/extra/x86_64/openmp/files/)
without any versioning resolution.

Should make it explicit what the compatibility guarantees for
libomptarget are, maybe even discourage OS distributions to
pre-package libomptarget into ldconfig default paths? At least on Arch
Linux updating the openmp package will break previously
compiled-with-offloading binaries.

Michael