[polly] r228914 - Link LLVM libraries into libLLVMPolly if BUILD_SHARED_LIBS=ON is set

[Tobias Grosser]

On 12.02.2015 15:02, Brad King wrote:
> On 2/12/2015 3:36 AM, Tobias Grosser wrote:
>>> URL: http://llvm.org/viewvc/llvm-project?rev=228914&view=rev
>>> Log:
>>> Link LLVM libraries into libLLVMPolly if BUILD_SHARED_LIBS=ON is set
>>>
>> I just "fixed" an issue I have with my cmake files, but I am afraid this
>> is not the optimal solution. Could you possibly cross-check what I did.
>
> For reference, here are the key parts of the CMakeLists.txt file:
>
>   add_polly_library(Polly ...)
>   if (BUILD_SHARED_LIBS)
>     target_link_libraries(Polly LLVMSupport ...)
>   endif()
>   add_polly_loadable_module(LLVMPolly ...)
>   target_link_libraries(LLVMPolly Polly)
>
> I didn't dive deep into the rest of the Polly code, but from the
> description of your change I surmise the following.
>
> The "target_link_libraries(Polly ...)" call says "link Polly and
> any of its dependents to these LLVM libraries".  If Polly is a
> shared library even when the LLVM libraries are static, then this
> will put a copy of them into Polly.  Then the later rule to link
> LLVMPolly to Polly causes the link dependencies to be followed
> transitively so LLVMPolly may get a copy of the static libs too,
> leading to the duplicate symbols.
>
> If "LLVMPolly" does not use any LLVM APIs directly and is just a
> loadable module wrapper around the "Polly" shared library, then
> it of course does not need to link to the LLVM libraries.  If all
> this is correct then you should just need to add LINK_PRIVATE
> to the first tll call and then it can be unconditional:
>
>   target_link_libraries(Polly LINK_PRIVATE LLVMSupport ...)
>
> This says "the implementation of Polly depends on these libraries,
> but dependents of Polly do not".  This is typical when the headers
> of a library do not expose its implementation dependencies.

Hi Brad,

thanks for your quick reply. I just tried your suggestion, but it does 
not solve the problem in case BUILD_SHARED_LIBS is turned off. I get an 
then the error:

opt: CommandLine Error: Option 'vectorize-loops' registered more than once!

To my understanding, the LLVM libraries are now linked into libPolly.a
and when loading libLLVMPolly.so e.g. into clang or opt, certain static
globals are defined twice (once hidden in Polly and once in clang/opt
itself). As such symbols register themselves, this causes problems.

I think having the libraries linked into libPolly.a is not the right 
approach. However, if I leave them out I get troubles with 
BUILD_SHARED_LIBS, when libPolly.so is built as libPolly.so requires 
some symbols that will be provided only when libPolly.so (through 
libLLVMPolly.so) is loaded into clang/opt.

My workaround links these libraries conditionally to libPolly:

if (BUILD_SHARED_LIBS)
   target_link_libraries(Polly
     LLVMSupport
     LLVMCore
     LLVMScalarOpts
     LLVMInstCombine
     LLVMTransformUtils
     LLVMAnalysis
     LLVMipo
   )
endif()

This does not cause any problems as these libraries will not be linked 
into libPolly in BUILD_SHARED_LIBS mode, but they will only be 
referenced as shared libraries. As a result all dependences are 
fulfilled, but no double-definitions are introduced.

My workaround works somehow, but I wonder if there is a way to teach 
cmake that libPolly indeed depends on a couple of libraries which need 
to be considered in BUILD_SHARED_LIBS mode when the availability of 
symbols is checked, but that should not be linked into libPolly itself.

Best,
Tobias