[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