<div dir="ltr">Revisiting this thread after a long break.<div><br></div><div>While I prefer having the arch in the name (to match the other runtimes), including an arch-specific subdirectory might be least intrusive to other downstream projects.</div><div><br></div><div>I'll change the driver to include a subdirectory in the resource dir (lib/clang/5.0.0/lib/linux/<arch>) when openmp is requested.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 12, 2016 at 4:28 PM, Dan Albert <span dir="ltr"><<a href="mailto:danalbert@google.com" target="_blank">danalbert@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I was assuming we'd rather have the implementations for arch-specific libraries all match (so the way to find an openmp library is the same as finding an asan library). Whether these get different names or different directories doesn't make much of a difference to me. The driver isn't currently searching in an architecture specific directory for the openmp library though, so if that's we choose to go with that will still need to be fixed.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 12, 2016 at 2:52 PM, Pirama Arumuga Nainar <span dir="ltr"><<a href="mailto:pirama@google.com" target="_blank">pirama@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+danalbert</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 10, 2016 at 11:04 AM, C Bergström <span dir="ltr"><<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm a bit more biased towards not mixing different arch in the same<br>
directory. The Solaris/Linux? solution of 1 arch per directory means<br>
that the only thing needed is just looking in ${arch}/lib or something<br>
along those lines. If using this as a solution then everything arch<br>
specific can live there.. (Would this overlap and help sanitizer as<br>
well?)<br>
<br>
Long term driver special rules are a pita to maintain and unlikely to<br>
lead to good design..<br>
<div><div class="m_-2980788690160964836m_-2475211880775942558h5"><br>
On Sat, Dec 10, 2016 at 7:09 AM, Pirama Arumuga Nainar via Openmp-dev<br>
<<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>> wrote:<br>
> Reposting PR <a href="https://llvm.org/bugs/show_bug.cgi?id=31300" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug<wbr>.cgi?id=31300</a> to reach a wider<br>
> audience.  Can you please share any thoughts?<br>
><br>
> Currently, '-fopenmp' just gets translated to the corresponding runtime<br>
> library (-lomp, -lgomp, -lipmp5) during the link step.  However, this<br>
> precludes a multilib toolchain from finding the right library based on the<br>
> target architecture without extra support from the build system.  The<br>
> sanitizers, for instance, use libclang_rt.<sanitizer>-<arch><wbr>.{so,a}.<br>
><br>
> To do something similar for OpenMP, we need to<br>
> 1. change the driver to pass the extended name to the linker.<br>
> 2. change the CMake build rules to use the extended name instead of<br>
> libomp.so.<br>
><br>
> My questions:<br>
> 1. What is the preferred "full" name?  libomp-<arch>.so sounds reasonable to<br>
> me.<br>
> 2. Is the existing behavior preferable to avoid breaking existing code or to<br>
> support OpenMP runtimes from outside of this project?  If so, I can make the<br>
> above changes fire only for Android triples.  In this case, we don't need to<br>
> immediately update CMake build rules.<br>
><br>
><br>
</div></div>> ______________________________<wbr>_________________<br>
> Openmp-dev mailing list<br>
> <a href="mailto:Openmp-dev@lists.llvm.org" target="_blank">Openmp-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/openmp-dev</a><br>
><br>
</blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>