From reSIProcate
Jump to navigation Jump to search

This page summarises the migration status.

There is a summary of platforms tested, and a summary of general issues, and some hints for people wanting to test.

Platforms tested


Platform detail: Debian squeeze (amd64 and i386)

Status: stack, resip, apps all built. Test cases run. Debian packages built:


Platform detail: OpenCSW build farm - all recent Sparc and x86 variants, zones, etc

Status: stack builds fully on stlport, test cases run. repro fails to link against csw/libdb, because csw is linked with libCstd (not stlport compatible)

Stack fails to build as libCstd, discussed on mailing list:

Note: Solaris issues (stlport and libCstd) are not at all related to the choice of build system. Use of stlport can be chosen manually (if a suitable libdb is available or not required) by passing the arguments to configure:

 ./configure CXXFLAGS="-library=stlport" LDFLAGS="-library=stlport"

More complete example for Solaris:

 autoreconf --install 
 ./configure \
     CC=/opt/studio/sunstudio12.1/bin/cc \
     CXX=/opt/studio/sunstudio12.1/bin/CC \
     CPPFLAGS="-I/opt/csw/include -I/opt/csw/bdb48/include -mt -V -v" \
     LDFLAGS="-L/opt/csw/lib -L/opt/csw/bdb48/lib -DTHREAD=MULTI -mt -dalign -V -v" \
     --with-c-ares --with-ssl
 gmake -j12

(Note that OpenCSW build servers have gmake rather than make)

Darwin / MacOS

Platform detail: two test machines provided by Philip and Adam, 10.6 (Snow Leopard) and 10.7 (Lion)

When Adam first tried, the build failed with errors about librt. Daniel has recently tried to fix this, now the whole stack builds and test cases can run.

To build repro and then test cases (verified on both 10.6 and 10.7):

(Note: for 10.6, use db46 and for 10.7, you can use db48)

 git svn clone -Tmain resip-trunk.git
 cd resip-trunk.git
 cd contrib/ares && ./configure && make && cd ../..
 autoreconf --install
 ./configure --with-ssl CPPFLAGS="-I/opt/local/include/db46 -I/opt/local/include/ -I/opt/local/include/boost/" LDFLAGS="-L/opt/local/lib/db46"
 make -C rutil check


Platform detail: tested by Scott

Comments: the Windows build system has not been changed, it does not use autotools. However, the autotools change resulted in us using a top-level config.h, and many files were modified to refer to config.h. No new variables are defined in config.h: only variables that existed under the old build system, therefore, there should be no impact to Windows.

General issues

Corrections to pre-processor conditional logic

There were some other minor corrections to pre-processor conditional logic (bad use of #if instead of #ifdef) that could result in the stack behaving slightly differently (on all platforms)

Stricter C++ compatibility

The attempts to build on Solaris / SunPro toolchain revealed minor mismatches in prototypes and other issues that were ignored by g++ on Linux. These issues have been rectified in the code.


A documentation review is in progress. See these files for some brief but up to date examples:

Tips for building

configure --help will show the custom options for resiprocate:

 --with-c-ares           Link against libc-ares (rather than contrib/ares)
 --with-ssl              Link against OpenSSL libraries
 --with-sigcomp          Link against Open SigComp libraries for SigComp
 --with-mysql            Link against MySQL client libraries
 --with-radius           Link against RADIUS client libraries
 --with-tfm              Build TFM, links against Netxx and cppunit
 --with-apps             Build apps, links against various things
 --with-recon            Build recon, links against sipX
 --with-p2p              Build P2P, links against S2C and SSL, unfinished

If not using --with-c-ares, it is necessary to manually configure and build contrib/ares before building the main stack:

 cd contrib/ares && ./configure && make && cd ../..
 ./configure --with-ssl && make

If any headers or libraries are not in the expected locations, please just add CPPFLAGS and LDFLAGS to configure, e.g.

 ./configure --with-ssl CPPFLAGS="-I/opt/local/include/db48" LDFLAGS="-L/opt/local/lib/db48"

configure should not be modified to try to find things in unusual places. Some other autotools projects attempt such things, but it only makes the code more messy and inflexible for cross-compiling.