[Openmp-dev] Pass arch-specific OpenMP library name to the linker

[Pirama Arumuga Nainar via Openmp-dev]

Revisiting this thread after a long break.

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.

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.

On Mon, Dec 12, 2016 at 4:28 PM, Dan Albert <danalbert at google.com> wrote:

> 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.
>
> On Mon, Dec 12, 2016 at 2:52 PM, Pirama Arumuga Nainar <pirama at google.com>
> wrote:
>
>> +danalbert
>>
>> On Sat, Dec 10, 2016 at 11:04 AM, C Bergström <cbergstrom at pathscale.com>
>> wrote:
>>
>>> I'm a bit more biased towards not mixing different arch in the same
>>> directory. The Solaris/Linux? solution of 1 arch per directory means
>>> that the only thing needed is just looking in ${arch}/lib or something
>>> along those lines. If using this as a solution then everything arch
>>> specific can live there.. (Would this overlap and help sanitizer as
>>> well?)
>>>
>>> Long term driver special rules are a pita to maintain and unlikely to
>>> lead to good design..
>>>
>>> On Sat, Dec 10, 2016 at 7:09 AM, Pirama Arumuga Nainar via Openmp-dev
>>> <openmp-dev at lists.llvm.org> wrote:
>>> > Reposting PR https://llvm.org/bugs/show_bug.cgi?id=31300 to reach a
>>> wider
>>> > audience.  Can you please share any thoughts?
>>> >
>>> > Currently, '-fopenmp' just gets translated to the corresponding runtime
>>> > library (-lomp, -lgomp, -lipmp5) during the link step.  However, this
>>> > precludes a multilib toolchain from finding the right library based on
>>> the
>>> > target architecture without extra support from the build system.  The
>>> > sanitizers, for instance, use libclang_rt.<sanitizer>-<arch>.{so,a}.
>>> >
>>> > To do something similar for OpenMP, we need to
>>> > 1. change the driver to pass the extended name to the linker.
>>> > 2. change the CMake build rules to use the extended name instead of
>>> > libomp.so.
>>> >
>>> > My questions:
>>> > 1. What is the preferred "full" name?  libomp-<arch>.so sounds
>>> reasonable to
>>> > me.
>>> > 2. Is the existing behavior preferable to avoid breaking existing code
>>> or to
>>> > support OpenMP runtimes from outside of this project?  If so, I can
>>> make the
>>> > above changes fire only for Android triples.  In this case, we don't
>>> need to
>>> > immediately update CMake build rules.
>>> >
>>> >
>>> > _______________________________________________
>>> > Openmp-dev mailing list
>>> > Openmp-dev at lists.llvm.org
>>> > http://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/20170210/3cc09000/attachment.html>