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

[Johannes Doerfert via Openmp-dev]

On 7/9/20 3:57 PM, Jonas Hahnfeld via Openmp-dev wrote:
> 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.

Right, this thread was not about *any* `.so` runtime.



> Jonas
>
> _______________________________________________
> Openmp-dev mailing list
> Openmp-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200709/cbacd4d1/attachment-0001.html>