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

[Jonas Hahnfeld via Openmp-dev]

Am Donnerstag, den 09.07.2020, 15:39 -0500 schrieb Michael Kruse via
Openmp-dev:
> 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.

I asked the maintainer to install libomptarget and the plugin because
otherwise there are link errors when compiling an OpenMP application
with target directives. That's worse from a users perspective.

Really, this thread was about the device runtime which I still think
would be nice to keep working with one released version of Clang. Based
on the other comments in this thread, that's not going to happen -
acknowledged.
The host runtimes on the other side are linked dynamically and IMO it's
one of the strengths of libomp to mix-and-match versions. Unless
there's a compelling reason, I'll make another plea to keep
compatibility.

Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200709/23d2d338/attachment.sig>