The cmake mailing list may not have sufficient context, so let me add
some details.

Polly is an extension library for LLVM. Both can be configured in
multiple configurations:

LLVM can be
- A bunch of libLLVM*.a files
- A bunch of libLLVM*.so files
- A single libLLVM.so file

Polly can be
- LLVMPolly.so to be loaded dynamically into the LLVM host application
  using an LD_PRELOAD-like mechanism (e.g. clang or opt)
- Linked directly into the LLVM host application (target_link_library)
  - as dynamic library libPolly.so
  - as static library libPolly.a

and it should work with all combinations of these.

The issue is not all host applications always have all LLVM components
linked into it. In the example below, there is the Julia compiler
which does not have the NVPTX backend in it, but it is required by
(some configuration of) Polly.

Hence if we have an LLVMPolly.so we don't know whether the host
program has the LLVMNVPTX* libraries in it. If we do not depend on
these libraries, the linker will complain about missing symbols if the
host doesn't have these either. If we do depend on these libraries,
and the host has them as well, we risk having the same library
multiple times in the address space (e.g. LLVMNVPTX* is statically
linked into libLLVM.so, but LLVMPolly.so contains them as well). This
is a problem, because for instance, static initializers (".ctors")
register some command-line options. It is an error if two libraries
(or two copies of the same library) register the same command-line
option twice.

This is not really a cmake-specific question, and the solution I
proposed to Sanjay to require the host application to have all
required components already linked into it. We can do this for clang,
opt (and bugpoint), but the Julia compiler guys do not like to depend
on the NVPTX backend, which they usually do not use.

Michael


2017-04-20 17:56 GMT+02:00 Sanjay Srivallabh Singapuram
<singapuram.san...@gmail.com>:
> Hello,
>
> I'm proposing a patch to the Polly/LLVM project that involves linking
> libPolly.a or libPolly.so to NVPTX back-end libraries. I'm currently using,
> target_link_libraries(Polly
>       LLVMNVPTXCodeGen
>       LLVMNVPTXInfo
>       LLVMNVPTXDesc
>       LLVMNVPTXAsmPrinter
>       )
>
> The opt binary links to both Polly and NVPTX back-end libraries, therefore
> including the back-end libraries twice which causes problems. Can linking
> the libraries as an INTERFACE to Polly solve the problem ?
>
> target_link_libraries(Polly INTERFACE
>       LLVMNVPTXCodeGen
>       LLVMNVPTXInfo
>       LLVMNVPTXDesc
>       LLVMNVPTXAsmPrinter
>       )
>
> Thank You,
> Sanjay
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Reply via email to