<div dir="ltr">Thanks a lot for the context Michael !<br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 20 Apr 2017 at 22:03 Michael Kruse <<a href="mailto:meinersbur@googlemail.com">meinersbur@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The cmake mailing list may not have sufficient context, so let me add<br>
some details.<br>
<br>
Polly is an extension library for LLVM. Both can be configured in<br>
multiple configurations:<br>
<br>
LLVM can be<br>
- A bunch of libLLVM*.a files<br>
- A bunch of libLLVM*.so files<br>
- A single libLLVM.so<br>
<br>
Polly can be<br>
- LLVMPolly.so to be loaded dynamically into the LLVM host application<br>
using an LD_PRELOAD-like mechanism (e.g. clang or opt)<br>
- Linked directly into the LLVM host application (target_link_library)<br>
  - as dynamic library libPolly.so<br>
  - as static library libPolly.a<br>
<br>
and it should work with all combinations of these.<br>
<br>
The issue is not all host applications always have all LLVM components<br>
linked into it. In the example below, there is the Julia compiler<br>
which does not have the the NVPTX backend in it, but it is required by<br>
(some configuration of) Polly.<br>
<br>
Hence if we have an LLVMPolly.so we don't know whether the host<br>
program has the LLVMNVPTX* libraries in it. If we do not depend on<br>
these libraries, the linker will complain about missing symbols if the<br>
host doesn't have these either. If we do depend on these libraries,<br>
and the host has them as well, we risk having the same library<br>
multiple times in the address space (e.g. LLVMNVPTX* is statically<br>
linked into libLLVM.so, but LLVMPolly.so contains them as well).<br>
<br>
This is not really a cmake-specific question, and the solution I<br>
proposed to Sanjay to require the host application to have all<br>
required components already linked into it. We can do this for clang,<br>
opt (and bugpoint), but the Julia compiler guys do not like to depend<br>
of the NVPTX backend, which they usually do not use.<br>
<br>
Michael<br>
<br>
<br>
<br>
2017-04-20 17:56 GMT+02:00 Sanjay Srivallabh Singapuram<br>
<<a href="mailto:singapuram.sanjay@gmail.com" target="_blank">singapuram.sanjay@gmail.com</a>>:<br>
> Hello,<br>
><br>
> I'm proposing a patch to the Polly/LLVM project that involves linking<br>
> libPolly.a or libPolly.so to NVPTX back-end libraries. I'm currently using,<br>
> target_link_libraries(Polly<br>
>       LLVMNVPTXCodeGen<br>
>       LLVMNVPTXInfo<br>
>       LLVMNVPTXDesc<br>
>       LLVMNVPTXAsmPrinter<br>
>       )<br>
><br>
> The opt binary links to both Polly and NVPTX back-end libraries, therefore<br>
> including the back-end libraries twice which causes problems. Can linking<br>
> the libraries as an INTERFACE to Polly solve the problem ?<br>
><br>
> target_link_libraries(Polly INTERFACE<br>
>       LLVMNVPTXCodeGen<br>
>       LLVMNVPTXInfo<br>
>       LLVMNVPTXDesc<br>
>       LLVMNVPTXAsmPrinter<br>
>       )<br>
><br>
> Thank You,<br>
> Sanjay<br>
<br>
<br>
<br>
--<br>
Tardyzentrismus verboten!<br>
</blockquote></div>