[CMake] Prevent libraries from linking twice during LLVM build

[Michael Kruse]

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.sanjay at 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