MantisBT - CMake
View Issue Details
0008992CMakeModulespublic2009-05-09 18:022016-06-10 14:30
Daniel Tihelka 
Bill Hoffman 
normalminoralways
closedmoved 
CMake-2-6 
 
0008992: CMAKE_SHARED_LINKER_FLAGS are not taken into account in SWIG_LINK_LIBRARIES
When UseSWIG modules is used and SWIG_LINK_LIBRARIES is called, it produces .so library - at least for Python and Java, I did not try other languages, but I suppose that it is the same for most (in not all) of them.

I expect that the fact that .so library is built implies that flags set for CMAKE_SHARED_LINKER_FLAGS define are used. However, it seems not to be truth. Is it design decision or just omission?

P.S. ADD_LIBRARY() works correctly.
No tags attached.
Issue History
2009-05-09 18:02Daniel TihelkaNew Issue
2009-09-14 15:04Bill HoffmanNote Added: 0017470
2009-09-14 15:04Bill HoffmanStatusnew => assigned
2009-09-14 15:04Bill HoffmanAssigned To => Bill Hoffman
2010-01-07 07:02Daniel TihelkaNote Added: 0019046
2010-07-04 07:37donblasNote Added: 0021224
2010-07-04 14:28donblasNote Added: 0021236
2016-06-10 14:27Kitware RobotNote Added: 0041555
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:30Kitware RobotStatusresolved => closed

Notes
(0017470)
Bill Hoffman   
2009-09-14 15:04   
I think it uses a MODULE and not a shared library.
(0019046)
Daniel Tihelka   
2010-01-07 07:02   
Well, but it builds shared library, didn't it ;-)

So I thought that the options set in CMAKE_SHARED_LINKER_FLAGS are/should be passed to a compiler when the shared library is built.

Setting verbose makefile, it produces something like (paths simplyfied):

[ 94%] Swig source
cd /home/.../wrap/python && /usr/bin/swig -python -I/home/.../wrap/python/ -outdir /home/.../wrap/python -c++ -I/home/.../src -I/usr/include/python2.5 -o /home/.../wrap/python/MyLibPYTHON_wrap.cxx /home/.../MyLib.i
/usr/bin/cmake -E cmake_progress_report /home/.../CMakeFiles 53

[ 96%] Building CXX object wrap/python/.../MyLibPYTHON_wrap.cxx.o
cd /home/.../wrap/python && /usr/bin/c++ -O3 -DNDEBUG -fPIC -I/home/.../src -I/usr/include/python2.5 -o CMakeFiles/.../MyLibPYTHON_wrap.cxx.o -c /home/.../wrap/python/MyLibPYTHON_wrap.cxx

Linking CXX shared module _mylib.so
cd /home/.../wrap/python && /usr/bin/cmake -E cmake_link_script CMakeFiles/_mylib.dir/link.txt --verbose=1

/usr/bin/c++ -fPIC -O3 -DNDEBUG -fPIC -shared -Wl,-soname,_mylib.so -o _mylib.so CMakeFiles/.../MyLibPYTHON_wrap.cxx.o ../../src/MyLib.a


but I would like the value of ${CMAKE_SHARED_LINKER_FLAGS} appear in the last step command, like:

/usr/bin/c++ -fPIC -O3 -DNDEBUG -fPIC -shared value_of_CMAKE_SHARED_LINKER_FLAGS_option .....
(0021224)
donblas   
2010-07-04 07:37   
I've run into this issue as well. Any timetable on a solution/workaround?
(0021236)
donblas   
2010-07-04 14:28   
So as a nasty workaround, one can use something like:

IF(UNIX)
     SET_TARGET_PROPERTIES(${SWIG_MODULE_${CSHARP_LIB_NAME}_REAL_NAME} PROPERTIES LINK_FLAGS "-Wl,-rpath,.")
ENDIF()

and use the internal REAL_NAME macro to set the needed LINK_FLAGS.

Post on issue:
http://iferrorthrownewbrick.blogspot.com/2010/07/will-penguin-in-room-please-stand-up.html [^]
(0041555)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.