[CMake] UseSWIG creates module instead of shared library, which can't be dynamically loaded

Stephen Roderick kiwi.net at mac.com
Thu Aug 6 11:30:24 EDT 2009


On Aug 6, 2009, at 10:23 , Clinton Stimpson wrote:

> On 08/06/2009 06:49 AM, Mathieu Malaterre wrote:
>>
>> On Thu, Aug 6, 2009 at 2:46 PM, Mathieu
>> Malaterre<mathieu.malaterre at gmail.com> wrote:
>>
>>> On Thu, Aug 6, 2009 at 2:27 PM, Stephen Roderick<kiwi.net at mac.com>  
>>> wrote:
>>>
>>>> On Aug 6, 2009, at 06:02 , Mathieu Malaterre wrote:
>>>>
>>>>
>>>>> On Wed, Aug 5, 2009 at 6:55 PM, Stephen  
>>>>> Roderick<kiwi.net at mac.com> wrote:
>>>>>
>>>>>> The existing UseSWIG.cmake file creates a MODULE and not a SHARED
>>>>>> library.
>>>>>> The module is unuseable by any program trying to load dynamic  
>>>>>> libraries
>>>>>> (eg
>>>>>> wrapped Java). The attached patch fixes this problem for our  
>>>>>> situations.
>>>>>> Demonstrated on both Mac OS X Leopard and Ubuntu Jaunty.
>>>>>>
>>>>>> Is this a known issue? I searched what I could of the list and  
>>>>>> the 'net,
>>>>>> and
>>>>>> couldn't find anything on this.
>>>>>>
>>>>> No, you are confusing the C++ library and the Java binding.  
>>>>> Instead:
>>>>>
>>>>> ADD_LIBRARY(foo SHARED ${foo_SRCS}) # the actual shared lib
>>>>> SWIG_ADD_MODULE(foojni java foo.i)
>>>>> SWIG_LINK_LIBRARIES(foojni foo
>>>>>  ${JNI_LIBRARIES}
>>>>> )
>>>>>
>>>>> The next time you will want to create -say- a python module you'll
>>>>> simply link to your *shared C++* library:
>>>>>
>>>>> SWIG_ADD_MODULE(foopython python foo.i)
>>>>> SWIG_LINK_LIBRARIES(foopython foo
>>>>>  ${PYTHON_LIBRARIES}
>>>>> )
>>>>>
>>>> Unfortunately, that is what we currently have.
>>>>
>>>> <code>
>>>>  ADD_LIBRARY(MyInterfaceCpp ...)
>>>>
>>>>  Find_Package(SWIG REQUIRED)
>>>>  Find_Package(JNI REQUIRED)
>>>>  INCLUDE(UseSWIG)
>>>>  INCLUDE_DIRECTORIES(${JAVA_INCLUDE_PATH} ${JAVA_INCLUDE_PATH2})
>>>>
>>>>  SET_SOURCE_FILES_PROPERTIES(MyInterface.i PROPERTIES CPLUSPLUS 1)
>>>>  # compile swig with package flag
>>>>  SET(CMAKE_SWIG_FLAGS -package x.y.z)
>>>>
>>>>  SWIG_ADD_MODULE(MyInterface java MyInterface.i)
>>>>  SWIG_LINK_LIBRARIES(MyInterface
>>>>        MyInterfaceCpp ...)
>>>> </code>
>>>>
>>>> The failure comes when you try to load the SWIG-output, JNI  
>>>> library from
>>>> within java, using something like
>>>> <code>
>>>>        static {
>>>>                System.loadLibrary("MyInterface");
>>>>        }
>>>> </code>
>>>>
>>>> With a module in a "MyInterface.so" file (what SWIG currently  
>>>> outputs), the
>>>>
>>> No. On Linux 'lib' is always preprended, even for MODULE. I am not
>>> sure about MacOSX.
>>>
>>>
>>>> above call fails on both Mac OS X and Linux. They both need a  
>>>> correctly
>>>> named dynamic library, hence the patch.
>>>>
>>> I have been using this in gdcm and it works fine on Linux:
>>>
>>> http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Wrapping/Java/gdcm.i?r1=5779&r2=5799
>>>
>>
>> My bad... I forgot that SWIG stuff always override the 'lib' setting,
>> hence you have to revert it:
>>
>> http://gdcm.svn.sf.net/viewvc/gdcm/trunk/Wrapping/Java/CMakeLists.txt?view=markup
>>
>> See comments:
>> ...
>>  IF(UNIX)
>>    SET_TARGET_PROPERTIES(${SWIG_MODULE_gdcmjni_REAL_NAME} PROPERTIES
>> PREFIX "lib")
>>  ENDIF(UNIX)
>> ...
>>
>> I think this comes from the SWIG module initially designed based on
>> the python requirement where '_' would be preprended before the  
>> actual
>> lib name.
>>
>> Sorry for the confusion.
>>
>
> And for python on Windows, I've had to do
> set_target_properties(... PROPERTIES SUFFIX ".pyd")
> or the module doesn't work with some versions of python.

We had to do both to get this right for Mac and Linux

   # force SWIG to generate a libXXX[.dylib] module file, not just  
XXX.so
   IF(UNIX)
	SET_TARGET_PROPERTIES(${SWIG_MODULE_xxx_REAL_NAME} PROPERTIES
	  PREFIX "lib")
	IF(APPLE)
	  SET_TARGET_PROPERTIES(${SWIG_MODULE_xxx_REAL_NAME} PROPERTIES
		SUFFIX ".dylib")
	ENDIF(APPLE)
   ENDIF(UNIX)

It would be nice if the UseSWIG.cmake file would figure this out for  
itself, but it might be a little complicated as is dependant on both  
target language and operating system.

Thanks for your help!
Stephen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090806/811d3fed/attachment.htm>


More information about the CMake mailing list