Prevent libraries from linking twice during LLVM build

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Prevent libraries from linking twice during LLVM build

Sanjay Srivallabh Singapuram
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 | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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
<[hidden email]>:

> 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 | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Prevent libraries from linking twice during LLVM build

Sanjay Srivallabh Singapuram
In reply to this post by Sanjay Srivallabh Singapuram
Thanks a lot for the context Michael !

On Thu, 20 Apr 2017 at 22:03 Michael Kruse <[hidden email]> 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
<[hidden email]>:
> 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
Loading...