Dependencies
Ssrc C++/Lua/Perl/Python/Ruby Bindings for Spread is not a standalone library. You must first install and configure the Spread Toolkit from Spread Concepts LLC before you can compile programs with libssrcspread. Also, you must link against Spread as well as Ssrc C++/Lua/Perl/Python/Ruby Bindings for Spread. Spread versions 3.17.3, 4.x, and 5.x are all supported.
Prior to version 0.7.4, only Spread Toolkit version 4.x was supported. Starting with version 0.7.4, Spread Toolkit version 3.17.3 is also supported. However, MembershipInfo, Error::NetErrorOnSession, and Mailbox::kill() are removed from the API when compiling against version 3.17.3.
At the moment, Ssrc C++/Lua/Perl/Python/Ruby Bindings for Spread depends on the GNU development tool chain (g++, gmake, autoconf, automake, and libtool). To compile on Win32 platforms you will need a GNU development environment such as Cygwin or MinGW. The software has been tested on Linux 32/64-bit (2.6.x series kernel), FreeBSD 8.1, Solaris 10 32/64-bit, and Mac OS X 10.6.7.
The unit tests require Boost (www.boost.org) to compile and run. Generation of test code coverage data requires lcov (ltp.sourceforge.net/coverage/lcov.php). Generation of documentation requires doxygen (www.doxygen.org). None of these packages is required to compile the library.
Compiling
Run the configure script to generate the Makefiles.
configure --help
will list the configuration options. If the Spread C API headers and libraries are not installed in a default system location, you will have to tell configure how to find them with:
configure --with-spread=PATHNAME
Also, you may decide to use the –disable-namespace-versioning option to avoid having to recompile dynamically linked programs after upgrading the library.
To install:
make install
If Doxygen is available on your system, you can generate API documentation with:
make apidocs
If Boost is available on your system, you can compile and run the unit tests with:
make test
If lcov is available on your system in addition to Boost, then you can generate the code coverage data with:
make coverage
Lua, Perl, Python, and Ruby Bindings
The Lua, Perl, Python, and Ruby bindings are built using SWIG (www.swig.org). SWIG is detected automatically. If it cannot be found, you can specify its location with:
configure --with-swig=path
The Lua binding is built if lua is detected on your system. The Perl5 binding is built if perl is detected on your system. The Python binding is built if python is detected on your system, and the Ruby binding is built if ruby is detected on your system.
You can change the installation directory of the Lua binding with:
configure --with-lua-sitedir=path
You can change the installation directory of the Perl binding with:
configure --with-perl-sitedir=path
You can change the installation directory of the Ruby binding with:
configure --with-ruby-sitedir=path
Otherwise, the Lua, Perl, and Ruby bindings are installed relative to the system-default Ruby and Perl installation trees.
The Python binding currently is installed relative to the installation prefix. If you want to install it somewhere else, you will have to copy the files manually or run the setup.py script in the swig/python subdirectory as follows:
setup.py install --prefix=path
If you use custom installation locations for the modules, you can access them from your scripts by adding the directory containing the ssrc module for each language to your PERL5LIB, PYTHONPATH, and RUBYLIB environment variables. The LUA_CPATH environment variable may have to point to the actual _spread.so dynamic shared object instead of the directory where it is stored and the LUA_PATH environment variable may have to be set as well in order to find ssrc/spread.lua. The Ssrc C++/Lua/Perl/Python/Ruby Bindings for Spread C++ shared library and the Spread C shared library must also be available (e.g., via LD_LIBRARY_PATH or a default system library location).
Compilation Problems
You may run into problems compiling the Ruby binding with the GNU compiler (currently the only one supported by the build system). The GNU <unistd.h> header defines eaccess() as throwing an exception, but the Ruby intern.h header does not (at least for versions 1.8.4 and 1.8.5). This difference produces a compiler error. To work around this problem you can modify the eaccess declaration in intern.h to look as follows:
\#ifndef __USE_GNU int eaccess _((const char*, int)); \#endif
Finally, these bindings have been tested and verified with SWIG 2.0.3 Lua 5.1.4, Perl 5.12.3, Python 3.2, and Ruby 1.9.2, but may work with other versions.
64-bit Compilation Problems
You may also run into problems compiling any of the bindings on 64-bit systems if you are not careful with your compilation options and scripting environment. If you are not using a system-supplied compiler and are instead using a custom version of GCC, you may have to use
LDFLAGS="-m64 -shared-libgcc -Wl,-m,elf_x86_64"
Also, you must ensure that the binding language and Spread libraries are also compiled with the same 64-bit options as well as -fPIC in CFLAGS. The libssrcspread configure script will automatically add -fPIC to CXXFLAGS.
The Spread Toolkit will not function properly on some 64-bit systems. Although it may work properly on Linux, it will fail on FreeBSD and Solaris without the following patch (created against version 4.1.0): spread-4.1.0-64-bit.patch.
diff -r 52bd3bd6a97d daemon/scatter.h
--- a/daemon/scatter.h Sun Jun 21 21:32:42 2009 -0400
+++ b/daemon/scatter.h Wed May 11 17:17:07 2011 -0400
@@ -43,16 +43,16 @@
typedef struct dummy_scat_element{
char *buf;
- int len;
+ size_t len;
} scat_element;
typedef struct dummy_scatter {
- int num_elements;
+ size_t num_elements;
scat_element elements[ARCH_SCATTER_SIZE];
} sys_scatter;
typedef struct dummy_big_scatter {
- int num_elements;
+ size_t num_elements;
scat_element elements[MAX_SCATTER_ELEMENTS];
} scatter;
diff -r 52bd3bd6a97d include/sp.h
--- a/include/sp.h Sun Jun 21 21:32:42 2009 -0400
+++ b/include/sp.h Wed May 11 17:17:07 2011 -0400
@@ -37,6 +37,9 @@
#ifndef INC_SP
#define INC_SP
+/* For size_t. */
+#include <sys/types.h>
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -136,11 +139,11 @@
typedef struct dummy_scat_element{
char *buf;
- int len;
+ size_t len;
} scat_element;
typedef struct dummy_scatter{
- int num_elements;
+ size_t num_elements;
scat_element elements[MAX_CLIENT_SCATTER_ELEMENTS];
} scatter;