Re: [CMake] CLANG vs GCC when linking executables

[Patrick Boettcher]

On Fri, 12 May 2017 17:30:16 +0200
Patrick Boettcher  wrote:
> The problem only occurs when the compiler is coming from a custom
> build from a custom path. Running 
>   
>   CXX=clang++ cmake 
> 
> makes cmake generate the correct link options.
> 
>   CXX=/local/path/bin/clang++ cmake 
> 
> makes cmake generate wrong link options (without RPATH).
> 
> Seems to be related the compiler-ID which is wrongly determined or
> something like that. 

I continued a bit more, it turns out that the placeholder
 (using the link.txt) does not contain the
rpath-options when linking with my locally generated compiler but it
present when using system compiler.

Where is LINK_LIBRARIES filled in? What option, features makes cmake
insert -Wl,rpath or not (as in my case)

--
Patrick.
-- 

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

Re: [CMake] CLANG vs GCC when linking executables

[Patrick Boettcher]

On Fri, 12 May 2017 16:57:25 +0200
Patrick Boettcher  wrote:

> Hi list,
> 
> I'm trying to link an executable with a locally build and imported
> dynamic library. The link-code generated by CMake differs when 
> using GCC and Clang in regards to the rpath-options:
> 
> This is my cmake-code for importing the library (this code is actually
> generated by using export() )
> 
>   add_library(systemc INTERFACE IMPORTED)
>   set_target_properties(systemc PROPERTIES
> INTERFACE_COMPILE_DEFINITIONS "SC_INCLUDE_FX"
> INTERFACE_COMPILE_OPTIONS "-Wno-deprecated-declarations"
> INTERFACE_INCLUDE_DIRECTORIES "/local/path/include"
> INTERFACE_LINK_LIBRARIES "/local/path/lib/libsystemc.so")
> 
>   add_executable(testsc test.cpp)
>   target_link_libraries(testsc systemc)
> 
> When now running cmake in a build-dir which uses by default gcc the
> link-command contains:
> 
>   /usr/bin/g++ CMakeFiles/testsc.dir/test.cpp.o  -o testsc \
> -Wl,-rpath,/local/path/lib /local/path/lib/libsystemc.so
> 
> doing the same with clang++ as CXX-compiler (CXX=clang++ cmake
> ) gives me a linker command not containing the
> -rpath-option:
> 
>   clang++ CMakeFiles/testsc.dir/test.cpp.o -o testsc \
> /local/path/lib/libsystemc.so
> 
> The link-process works, but when running the executable inside the
> build-dir it is unable to find the library as neither the rpath is set
> nor is this library-path known by the dynamic loader.
> 
> Is there anything I can do? Is this behavior expected? How should the
> RPATH being handled when clang is used.

The problem only occurs when the compiler is coming from a custom build
from a custom path. Running 
  
  CXX=clang++ cmake 

makes cmake generate the correct link options.

  CXX=/local/path/bin/clang++ cmake 

makes cmake generate wrong link options (without RPATH).

Seems to be related the compiler-ID which is wrongly determined or
something like that. 

--
Patrick.
-- 

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