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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

S Roderick
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.
Stephen

<code>
-- UseSWIG.cmake-save 2009-03-19 16:04:20.000000000 -0400
+++ UseSWIG.cmake 2009-03-19 16:04:44.000000000 -0400
@@ -33,7 +33,7 @@
      MESSAGE(FATAL_ERROR "SWIG Error: Language \"${language}\" not  
found")
    ENDIF("x${SWIG_MODULE_${name}_LANGUAGE}x" MATCHES "^xUNKNOWNx$")

-  SET(SWIG_MODULE_${name}_REAL_NAME "${name}")
+  SET(SWIG_MODULE_${name}_REAL_NAME "lib${name}")
    IF("x${SWIG_MODULE_${name}_LANGUAGE}x" MATCHES "^xPYTHONx$")
      SET(SWIG_MODULE_${name}_REAL_NAME "_${name}")
    ENDIF("x${SWIG_MODULE_${name}_LANGUAGE}x" MATCHES "^xPYTHONx$")
@@ -187,7 +187,7 @@
    SET_DIRECTORY_PROPERTIES(PROPERTIES
      ADDITIONAL_MAKE_CLEAN_FILES "${swig_extra_clean_files};$
{swig_generated_sources}")
    ADD_LIBRARY(${SWIG_MODULE_${name}_REAL_NAME}
-    MODULE
+    SHARED
      ${swig_generated_sources}
      ${swig_other_sources})
    SET_TARGET_PROPERTIES(${SWIG_MODULE_${name}_REAL_NAME}
</code>

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: UseSWIG creates module instead of shared library, which can't be dynamically loaded

Mathieu Malaterre
On Wed, Aug 5, 2009 at 6:55 PM, Stephen Roderick<[hidden email]> 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}
)


--
Mathieu
http://mathieumalaterre.com
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: UseSWIG creates module instead of shared library, which can't be dynamically loaded

S Roderick
On Aug 6, 2009, at 06:02 , Mathieu Malaterre wrote:

> On Wed, Aug 5, 2009 at 6:55 PM, Stephen Roderick<[hidden email]>  
> 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 above call fails on both Mac OS X and Linux. They both  
need a correctly named dynamic library, hence the patch.

After searching some more I did find a previous post of this on the  
CMake ML, and the solution there is basically the same as mine (except  
the user copied the SWIG macro into their own CMakeLists.txt and then  
made the same changes). If that poster and myself are not doing  
anything wrong, then UseSWIG.cmake needs to be modified to support  
both naming styles. Else others will just hit this again in the future.

http://www.cmake.org/pipermail/cmake/2008-October/024727.html

TIA
Stephen
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: UseSWIG creates module instead of shared library, which can't be dynamically loaded

Mathieu Malaterre
On Thu, Aug 6, 2009 at 2:27 PM, Stephen Roderick<[hidden email]> wrote:

> On Aug 6, 2009, at 06:02 , Mathieu Malaterre wrote:
>
>> On Wed, Aug 5, 2009 at 6:55 PM, Stephen Roderick<[hidden email]> 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

2cts
--
Mathieu
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: UseSWIG creates module instead of shared library, which can't be dynamically loaded

Mathieu Malaterre
On Thu, Aug 6, 2009 at 2:46 PM, Mathieu
Malaterre<[hidden email]> wrote:

> On Thu, Aug 6, 2009 at 2:27 PM, Stephen Roderick<[hidden email]> wrote:
>> On Aug 6, 2009, at 06:02 , Mathieu Malaterre wrote:
>>
>>> On Wed, Aug 5, 2009 at 6:55 PM, Stephen Roderick<[hidden email]> 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.
--
Mathieu
http://mathieumalaterre.com
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: UseSWIG creates module instead of shared library, which can't be dynamically loaded

Clinton Stimpson
On 08/06/2009 06:49 AM, Mathieu Malaterre wrote:
On Thu, Aug 6, 2009 at 2:46 PM, Mathieu
Malaterre[hidden email] wrote:
  
On Thu, Aug 6, 2009 at 2:27 PM, Stephen Roderick[hidden email] wrote:
    
On Aug 6, 2009, at 06:02 , Mathieu Malaterre wrote:

      
On Wed, Aug 5, 2009 at 6:55 PM, Stephen Roderick[hidden email] 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.

Clint


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: UseSWIG creates module instead of shared library, which can't be dynamically loaded

S Roderick
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[hidden email] wrote:
  
On Thu, Aug 6, 2009 at 2:27 PM, Stephen Roderick[hidden email] wrote:
    
On Aug 6, 2009, at 06:02 , Mathieu Malaterre wrote:

      
On Wed, Aug 5, 2009 at 6:55 PM, Stephen Roderick[hidden email] 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


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake