Thanks a lot for the context Michael ! On Thu, 20 Apr 2017 at 22:03 Michael Kruse <[email protected]> wrote:
> 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 > > 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 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 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 > of the NVPTX backend, which they usually do not use. > > Michael > > > > 2017-04-20 17:56 GMT+02:00 Sanjay Srivallabh Singapuram > <[email protected]>: > > 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 > > > > -- > Tardyzentrismus verboten! >
-- 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
