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.
Platform detail: Debian squeeze (amd64 and i386)
Status: stack, resip, apps all built. Test cases run. Debian packages built: http://mentors.debian.net/package/resiprocate
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: http://list.resiprocate.org/archive/resiprocate-devel/msg07995.html
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 https://svn.resiprocate.org/rep/resiprocate 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/" LDFLAGS="-L/opt/local/lib/db46" make 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.
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.