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

Dan Albert via Openmp-dev openmp-dev at lists.llvm.org
Mon Dec 12 16:28:52 PST 2016


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/20161212/85ad733f/attachment.html>


More information about the Openmp-dev mailing list