<div dir="auto"><div>Correct. <div dir="auto"><br></div><div dir="auto">I inferred from your response that we have no such guarantee yet, we just haven't broken it yet.</div><div dir="auto"><br></div><div dir="auto">However, I think that change will break ABI of libomptarget-nvptx.a</div><div dir="auto"><br></div><div dir="auto">Just want to clarify what ABI stability guarantees we have.</div><div dir="auto"><br></div><div dir="auto">Michael</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 9 juil. 2020 à 17:08, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 7/9/20 3:39 PM, Michael Kruse wrote:<br>
> Am Do., 9. Juli 2020 um 14:08 Uhr schrieb Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank" rel="noreferrer">hfinkel@anl.gov</a>>:<br>
>> Also, if we wanted to change clang so that it linked version-locked<br>
>> versions of these libraries, -lomptarget-11 or whatever, that, in my<br>
>> opinion, would also be a reasonable choice to discuss.<br>
>><br>
>> One thing worth capturing is the extent to which these things are<br>
>> connected. There is a relationship between libomptarget and its plugins,<br>
>> and the plugins and the device-side runtimes. There is an ABI boundary<br>
>> there somewhere. If we change nothing else, we might need to consider<br>
>> ABI stability of this part of the device-side interface.<br>
> The official distribution <a href="http://apt.llvm.org" rel="noreferrer noreferrer" target="_blank">apt.llvm.org</a> contains libomptarget.so for<br>
> LLVM 7 to 10, but each into separate directories under<br>
> /usr/lib/llvm-<version>/libomptarget.so. The prebuilt binaries under<br>
> <a href="https://releases.llvm.org/download.html" rel="noreferrer noreferrer" target="_blank">https://releases.llvm.org/download.html</a> puts it directly under<br>
> <prefix>/libomptarget.so. If libomptarget is version-locked, users<br>
> need to be careful about pointing to the right LD_LIBRARY_PATH.<br>
> However, I could not find target device plugins in the distributions<br>
> (such as lib/libomptarget-nvptx-sm_60.bc when built on a machine with<br>
> CUDA). The official ubuntu repository doesn't contain libomptarget at<br>
> all. Arch Linux contains at least the x86_64 rtl<br>
> (<a href="https://www.archlinux.org/packages/extra/x86_64/openmp/files/" rel="noreferrer noreferrer" target="_blank">https://www.archlinux.org/packages/extra/x86_64/openmp/files/</a>)<br>
> without any versioning resolution.<br>
><br>
> Should make it explicit what the compatibility guarantees for<br>
> libomptarget are, maybe even discourage OS distributions to<br>
> pre-package libomptarget into ldconfig default paths? At least on Arch<br>
> Linux updating the openmp package will break previously<br>
> compiled-with-offloading binaries.<br>
<br>
<br>
You mean that it will break them *if* we make an ABI-breaking change in <br>
libomptarget. Changing the device-side runtime doesn't necessarily imply <br>
that. Nevertheless, certainly good to know.<br>
<br>
  -Hal<br>
<br>
<br>
><br>
> Michael<br>
<br>
-- <br>
Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<br>
</blockquote></div></div></div>