[reSIProcate] public API, config.h and CPPflags issues
Daniel Pocock
daniel at pocock.com.au
Wed Jul 31 12:14:14 CDT 2013
Catalin and I have discovered issues trying to use the reSIProcate
headers to compile a standalone project
Basically, we had to duplicate many of the definitions into the
dependent project, as demonstrated in this commit:
https://github.com/catalinusurelu/reConServer/commit/8644e5d581c361fa5eee5f2fbf405cb3cc76f7fa
It is OK hardcoding these things for a known platform (Catalin is
testing the Debian packages, so he knows what flags I used for the
build) but not convenient for widespread usage.
Without having all the right flags, we observed that the compile would
succeed, process would run, but at some point later we would get a
segfault (for reConServer, the segfault occurs when the first call comes
in) so this is likely to be frustrating for other people trying to build
things that depend on reSIProcate.
I can think of a few ways to proceed:
best solution: can we make the public API completely static with respect
to compile flags? E.g. not using #ifdef USE_IPV6 or #ifdef USE_SSL in
*.hxx?
config.h: we can't distribute a full config.h from autotools - nor
should we, it will clash with config.h in dependent projects, we already
experienced that problem with srtp/config.h. We could create something
derived from config.h though and distribute that.
config binary: e.g. some script, bin/xxx-config that can be invoked
like this:
RESIP_CPPFLAGS=`/usr/bin/resip-config --cppflags`
I raised this on the autoconf mailing list too
http://lists.gnu.org/archive/html/autoconf/2013-07/msg00055.html
More information about the resiprocate-devel
mailing list