asterisk/third-party/pjproject/configure.m4

100 lines
4.2 KiB
Text
Raw Normal View History

#
# If this file is changed, be sure to run ASTTOPDIR/bootstrap.sh
# before committing.
#
AC_DEFUN([_PJPROJECT_CONFIGURE],
build-system: Allow building with static pjproject Background here: http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html From CHANGES: * To help insure that Asterisk is compiled and run with the same known version of pjproject, a new option (--with-pjproject-bundled) has been added to ./configure. When specified, the version of pjproject specified in third-party/versions.mak will be downloaded and configured. When you make Asterisk, the build process will also automatically build pjproject and Asterisk will be statically linked to it. Once a particular version of pjproject is configured and built, it won't be configured or built again unless you run a 'make distclean'. To facilitate testing, when 'make install' is run, the pjsua and pjsystest utilities and the pjproject python bindings will be installed in ASTDATADIR/third-party/pjproject. The default behavior remains building with the shared pjproject installation, if any. Building: All you have to do is include the --with-pjproject-bundled option on the ./configure command line (and remove any existing --with-pjproject option if specified). Everything else is automatic. Behind the scenes: The top-level Makefile was modified to include 'third-party' in the list of MOD_SUBDIRS. The third-party directory was created to contain any third party packages that may be needed in the future. Its Makefile automatically iterates over any subdirectories passing on targets. The third-party/pjproject directory was created to house the pjproject source distribution. Its Makefile contains targets to download, patch configure, generate dependencies, compile libs, apps and python bindings, sanitized build.mak and generate a symbols list. When bootstrap.sh is run, it automatically includes the configure.m4 file in third-party/pjproject. This file has a macro to download and conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR and PJPROJECT_BUNDLED. It also tests for the capabilities like PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to trying to compile. Of course, bootstrap.sh is only run once and the configure file is incldued in the patch. When configure is run with the new options, the macro in configure.m4 triggers the download, patch, conifgure and tests. No compilation is performed at this time. The downloaded tarball is cached in /tmp so it doesn't get downloaded again on a distclean. When make is run in the top-level Asterisk source directory, it will automatically descend all the subdirectories in third_party just as it does for addons, apps, etc. The top-level Makefile makes sure that the 'third-party' is built before 'main' so that dependencies from the other directories are built first. When main does build, a new shared library (libasteriskpj) is created that links statically to the pjproject .a files and exports all their symbols. The asterisk binary links to that, just as it does with libasteriskssl. When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject python bindings are installed in ASTDATADIR/third-party/pjproject. This will facilitate testing, including running the testsuite which will be updated to check that directory for the pjsua module ahead of the system python library. Modules should continue to depend on pjproject if they use pjproject APIs directly. They should not care about the implementation. No changes to any res_pjsip modules were made. Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-19 03:54:28 +00:00
[
if test "${ac_mandatory_list#*PJPROJECT*}" != "$ac_mandatory_list" ; then
AC_MSG_ERROR(--with-pjproject and --with-pjproject-bundled can't both be specified)
fi
build-system: Allow building with static pjproject Background here: http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html From CHANGES: * To help insure that Asterisk is compiled and run with the same known version of pjproject, a new option (--with-pjproject-bundled) has been added to ./configure. When specified, the version of pjproject specified in third-party/versions.mak will be downloaded and configured. When you make Asterisk, the build process will also automatically build pjproject and Asterisk will be statically linked to it. Once a particular version of pjproject is configured and built, it won't be configured or built again unless you run a 'make distclean'. To facilitate testing, when 'make install' is run, the pjsua and pjsystest utilities and the pjproject python bindings will be installed in ASTDATADIR/third-party/pjproject. The default behavior remains building with the shared pjproject installation, if any. Building: All you have to do is include the --with-pjproject-bundled option on the ./configure command line (and remove any existing --with-pjproject option if specified). Everything else is automatic. Behind the scenes: The top-level Makefile was modified to include 'third-party' in the list of MOD_SUBDIRS. The third-party directory was created to contain any third party packages that may be needed in the future. Its Makefile automatically iterates over any subdirectories passing on targets. The third-party/pjproject directory was created to house the pjproject source distribution. Its Makefile contains targets to download, patch configure, generate dependencies, compile libs, apps and python bindings, sanitized build.mak and generate a symbols list. When bootstrap.sh is run, it automatically includes the configure.m4 file in third-party/pjproject. This file has a macro to download and conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR and PJPROJECT_BUNDLED. It also tests for the capabilities like PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to trying to compile. Of course, bootstrap.sh is only run once and the configure file is incldued in the patch. When configure is run with the new options, the macro in configure.m4 triggers the download, patch, conifgure and tests. No compilation is performed at this time. The downloaded tarball is cached in /tmp so it doesn't get downloaded again on a distclean. When make is run in the top-level Asterisk source directory, it will automatically descend all the subdirectories in third_party just as it does for addons, apps, etc. The top-level Makefile makes sure that the 'third-party' is built before 'main' so that dependencies from the other directories are built first. When main does build, a new shared library (libasteriskpj) is created that links statically to the pjproject .a files and exports all their symbols. The asterisk binary links to that, just as it does with libasteriskssl. When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject python bindings are installed in ASTDATADIR/third-party/pjproject. This will facilitate testing, including running the testsuite which will be updated to check that directory for the pjsua module ahead of the system python library. Modules should continue to depend on pjproject if they use pjproject APIs directly. They should not care about the implementation. No changes to any res_pjsip modules were made. Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-19 03:54:28 +00:00
ac_mandatory_list="$ac_mandatory_list PJPROJECT"
PJPROJECT_DIR="${ac_top_build_prefix}third-party/pjproject"
build-system: Allow building with static pjproject Background here: http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html From CHANGES: * To help insure that Asterisk is compiled and run with the same known version of pjproject, a new option (--with-pjproject-bundled) has been added to ./configure. When specified, the version of pjproject specified in third-party/versions.mak will be downloaded and configured. When you make Asterisk, the build process will also automatically build pjproject and Asterisk will be statically linked to it. Once a particular version of pjproject is configured and built, it won't be configured or built again unless you run a 'make distclean'. To facilitate testing, when 'make install' is run, the pjsua and pjsystest utilities and the pjproject python bindings will be installed in ASTDATADIR/third-party/pjproject. The default behavior remains building with the shared pjproject installation, if any. Building: All you have to do is include the --with-pjproject-bundled option on the ./configure command line (and remove any existing --with-pjproject option if specified). Everything else is automatic. Behind the scenes: The top-level Makefile was modified to include 'third-party' in the list of MOD_SUBDIRS. The third-party directory was created to contain any third party packages that may be needed in the future. Its Makefile automatically iterates over any subdirectories passing on targets. The third-party/pjproject directory was created to house the pjproject source distribution. Its Makefile contains targets to download, patch configure, generate dependencies, compile libs, apps and python bindings, sanitized build.mak and generate a symbols list. When bootstrap.sh is run, it automatically includes the configure.m4 file in third-party/pjproject. This file has a macro to download and conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR and PJPROJECT_BUNDLED. It also tests for the capabilities like PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to trying to compile. Of course, bootstrap.sh is only run once and the configure file is incldued in the patch. When configure is run with the new options, the macro in configure.m4 triggers the download, patch, conifgure and tests. No compilation is performed at this time. The downloaded tarball is cached in /tmp so it doesn't get downloaded again on a distclean. When make is run in the top-level Asterisk source directory, it will automatically descend all the subdirectories in third_party just as it does for addons, apps, etc. The top-level Makefile makes sure that the 'third-party' is built before 'main' so that dependencies from the other directories are built first. When main does build, a new shared library (libasteriskpj) is created that links statically to the pjproject .a files and exports all their symbols. The asterisk binary links to that, just as it does with libasteriskssl. When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject python bindings are installed in ASTDATADIR/third-party/pjproject. This will facilitate testing, including running the testsuite which will be updated to check that directory for the pjsua module ahead of the system python library. Modules should continue to depend on pjproject if they use pjproject APIs directly. They should not care about the implementation. No changes to any res_pjsip modules were made. Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-19 03:54:28 +00:00
AC_MSG_CHECKING(for embedded pjproject (may have to download))
AC_MSG_RESULT(configuring)
if test "x${DOWNLOAD_TO_STDOUT}" = "x" ; then
AC_MSG_ERROR(A download utility (wget, curl or fetch) is required to download bundled pjproject)
fi
if test "${BZIP2}" = ":" ; then
AC_MSG_ERROR(bzip2 is required to extract the pjproject tar file)
fi
if test "${TAR}" = ":" ; then
AC_MSG_ERROR(tar is required to extract the pjproject tar file)
fi
if test "${PATCH}" = ":" ; then
AC_MSG_ERROR(patch is required to configure bundled pjproject)
fi
if test "${SED}" = ":" ; then
AC_MSG_ERROR(sed is required to configure bundled pjproject)
fi
if test "${NM}" = ":" ; then
AC_MSG_ERROR(nm is required to build bundled pjproject)
fi
if test "${MD5}" = ":" ; then
AC_MSG_ERROR(md5sum is required to build bundled pjproject)
fi
if test "${CAT}" = ":" ; then
AC_MSG_ERROR(cat is required to build bundled pjproject)
fi
AC_ARG_VAR([PJPROJECT_CONFIGURE_OPTS],[Additional configure options to pass to bundled pjproject])
this_host=$(./config.sub $(./config.guess))
if test "$build" != "$this_host" ; then
PJPROJECT_CONFIGURE_OPTS+=" --build=$build"
fi
if test "$host" != "$this_host" ; then
PJPROJECT_CONFIGURE_OPTS+=" --host=$host"
fi
export TAR PATCH SED NM EXTERNALS_CACHE_DIR AST_DOWNLOAD_CACHE DOWNLOAD_TO_STDOUT DOWNLOAD_TIMEOUT DOWNLOAD MD5 CAT
export NOISY_BUILD
${GNU_MAKE} --quiet --no-print-directory -C ${PJPROJECT_DIR} \
PJPROJECT_CONFIGURE_OPTS="$PJPROJECT_CONFIGURE_OPTS" \
EXTERNALS_CACHE_DIR="${EXTERNALS_CACHE_DIR:-${AST_DOWNLOAD_CACHE}}" \
configure
build-system: Allow building with static pjproject Background here: http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html From CHANGES: * To help insure that Asterisk is compiled and run with the same known version of pjproject, a new option (--with-pjproject-bundled) has been added to ./configure. When specified, the version of pjproject specified in third-party/versions.mak will be downloaded and configured. When you make Asterisk, the build process will also automatically build pjproject and Asterisk will be statically linked to it. Once a particular version of pjproject is configured and built, it won't be configured or built again unless you run a 'make distclean'. To facilitate testing, when 'make install' is run, the pjsua and pjsystest utilities and the pjproject python bindings will be installed in ASTDATADIR/third-party/pjproject. The default behavior remains building with the shared pjproject installation, if any. Building: All you have to do is include the --with-pjproject-bundled option on the ./configure command line (and remove any existing --with-pjproject option if specified). Everything else is automatic. Behind the scenes: The top-level Makefile was modified to include 'third-party' in the list of MOD_SUBDIRS. The third-party directory was created to contain any third party packages that may be needed in the future. Its Makefile automatically iterates over any subdirectories passing on targets. The third-party/pjproject directory was created to house the pjproject source distribution. Its Makefile contains targets to download, patch configure, generate dependencies, compile libs, apps and python bindings, sanitized build.mak and generate a symbols list. When bootstrap.sh is run, it automatically includes the configure.m4 file in third-party/pjproject. This file has a macro to download and conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR and PJPROJECT_BUNDLED. It also tests for the capabilities like PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to trying to compile. Of course, bootstrap.sh is only run once and the configure file is incldued in the patch. When configure is run with the new options, the macro in configure.m4 triggers the download, patch, conifgure and tests. No compilation is performed at this time. The downloaded tarball is cached in /tmp so it doesn't get downloaded again on a distclean. When make is run in the top-level Asterisk source directory, it will automatically descend all the subdirectories in third_party just as it does for addons, apps, etc. The top-level Makefile makes sure that the 'third-party' is built before 'main' so that dependencies from the other directories are built first. When main does build, a new shared library (libasteriskpj) is created that links statically to the pjproject .a files and exports all their symbols. The asterisk binary links to that, just as it does with libasteriskssl. When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject python bindings are installed in ASTDATADIR/third-party/pjproject. This will facilitate testing, including running the testsuite which will be updated to check that directory for the pjsua module ahead of the system python library. Modules should continue to depend on pjproject if they use pjproject APIs directly. They should not care about the implementation. No changes to any res_pjsip modules were made. Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-19 03:54:28 +00:00
if test $? -ne 0 ; then
AC_MSG_RESULT(failed)
AC_MSG_NOTICE(Unable to configure ${PJPROJECT_DIR})
AC_MSG_ERROR(Re-run the ./configure command with 'NOISY_BUILD=yes' appended to see error details.)
build-system: Allow building with static pjproject Background here: http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html From CHANGES: * To help insure that Asterisk is compiled and run with the same known version of pjproject, a new option (--with-pjproject-bundled) has been added to ./configure. When specified, the version of pjproject specified in third-party/versions.mak will be downloaded and configured. When you make Asterisk, the build process will also automatically build pjproject and Asterisk will be statically linked to it. Once a particular version of pjproject is configured and built, it won't be configured or built again unless you run a 'make distclean'. To facilitate testing, when 'make install' is run, the pjsua and pjsystest utilities and the pjproject python bindings will be installed in ASTDATADIR/third-party/pjproject. The default behavior remains building with the shared pjproject installation, if any. Building: All you have to do is include the --with-pjproject-bundled option on the ./configure command line (and remove any existing --with-pjproject option if specified). Everything else is automatic. Behind the scenes: The top-level Makefile was modified to include 'third-party' in the list of MOD_SUBDIRS. The third-party directory was created to contain any third party packages that may be needed in the future. Its Makefile automatically iterates over any subdirectories passing on targets. The third-party/pjproject directory was created to house the pjproject source distribution. Its Makefile contains targets to download, patch configure, generate dependencies, compile libs, apps and python bindings, sanitized build.mak and generate a symbols list. When bootstrap.sh is run, it automatically includes the configure.m4 file in third-party/pjproject. This file has a macro to download and conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR and PJPROJECT_BUNDLED. It also tests for the capabilities like PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to trying to compile. Of course, bootstrap.sh is only run once and the configure file is incldued in the patch. When configure is run with the new options, the macro in configure.m4 triggers the download, patch, conifgure and tests. No compilation is performed at this time. The downloaded tarball is cached in /tmp so it doesn't get downloaded again on a distclean. When make is run in the top-level Asterisk source directory, it will automatically descend all the subdirectories in third_party just as it does for addons, apps, etc. The top-level Makefile makes sure that the 'third-party' is built before 'main' so that dependencies from the other directories are built first. When main does build, a new shared library (libasteriskpj) is created that links statically to the pjproject .a files and exports all their symbols. The asterisk binary links to that, just as it does with libasteriskssl. When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject python bindings are installed in ASTDATADIR/third-party/pjproject. This will facilitate testing, including running the testsuite which will be updated to check that directory for the pjsua module ahead of the system python library. Modules should continue to depend on pjproject if they use pjproject APIs directly. They should not care about the implementation. No changes to any res_pjsip modules were made. Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-19 03:54:28 +00:00
fi
AC_MSG_CHECKING(for bundled pjproject)
PJPROJECT_INCLUDE=$(${GNU_MAKE} --quiet --no-print-directory -C ${PJPROJECT_DIR} PJPROJECT_CONFIGURE_OPTS="$PJPROJECT_CONFIGURE_OPTS" EXTERNALS_CACHE_DIR="${EXTERNALS_CACHE_DIR:-${AST_DOWNLOAD_CACHE}}" echo_cflags)
build-system: Allow building with static pjproject Background here: http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html From CHANGES: * To help insure that Asterisk is compiled and run with the same known version of pjproject, a new option (--with-pjproject-bundled) has been added to ./configure. When specified, the version of pjproject specified in third-party/versions.mak will be downloaded and configured. When you make Asterisk, the build process will also automatically build pjproject and Asterisk will be statically linked to it. Once a particular version of pjproject is configured and built, it won't be configured or built again unless you run a 'make distclean'. To facilitate testing, when 'make install' is run, the pjsua and pjsystest utilities and the pjproject python bindings will be installed in ASTDATADIR/third-party/pjproject. The default behavior remains building with the shared pjproject installation, if any. Building: All you have to do is include the --with-pjproject-bundled option on the ./configure command line (and remove any existing --with-pjproject option if specified). Everything else is automatic. Behind the scenes: The top-level Makefile was modified to include 'third-party' in the list of MOD_SUBDIRS. The third-party directory was created to contain any third party packages that may be needed in the future. Its Makefile automatically iterates over any subdirectories passing on targets. The third-party/pjproject directory was created to house the pjproject source distribution. Its Makefile contains targets to download, patch configure, generate dependencies, compile libs, apps and python bindings, sanitized build.mak and generate a symbols list. When bootstrap.sh is run, it automatically includes the configure.m4 file in third-party/pjproject. This file has a macro to download and conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR and PJPROJECT_BUNDLED. It also tests for the capabilities like PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to trying to compile. Of course, bootstrap.sh is only run once and the configure file is incldued in the patch. When configure is run with the new options, the macro in configure.m4 triggers the download, patch, conifgure and tests. No compilation is performed at this time. The downloaded tarball is cached in /tmp so it doesn't get downloaded again on a distclean. When make is run in the top-level Asterisk source directory, it will automatically descend all the subdirectories in third_party just as it does for addons, apps, etc. The top-level Makefile makes sure that the 'third-party' is built before 'main' so that dependencies from the other directories are built first. When main does build, a new shared library (libasteriskpj) is created that links statically to the pjproject .a files and exports all their symbols. The asterisk binary links to that, just as it does with libasteriskssl. When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject python bindings are installed in ASTDATADIR/third-party/pjproject. This will facilitate testing, including running the testsuite which will be updated to check that directory for the pjsua module ahead of the system python library. Modules should continue to depend on pjproject if they use pjproject APIs directly. They should not care about the implementation. No changes to any res_pjsip modules were made. Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-19 03:54:28 +00:00
PJPROJECT_CFLAGS="$PJPROJECT_INCLUDE"
PBX_PJPROJECT=1
build-system: Allow building with static pjproject Background here: http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html From CHANGES: * To help insure that Asterisk is compiled and run with the same known version of pjproject, a new option (--with-pjproject-bundled) has been added to ./configure. When specified, the version of pjproject specified in third-party/versions.mak will be downloaded and configured. When you make Asterisk, the build process will also automatically build pjproject and Asterisk will be statically linked to it. Once a particular version of pjproject is configured and built, it won't be configured or built again unless you run a 'make distclean'. To facilitate testing, when 'make install' is run, the pjsua and pjsystest utilities and the pjproject python bindings will be installed in ASTDATADIR/third-party/pjproject. The default behavior remains building with the shared pjproject installation, if any. Building: All you have to do is include the --with-pjproject-bundled option on the ./configure command line (and remove any existing --with-pjproject option if specified). Everything else is automatic. Behind the scenes: The top-level Makefile was modified to include 'third-party' in the list of MOD_SUBDIRS. The third-party directory was created to contain any third party packages that may be needed in the future. Its Makefile automatically iterates over any subdirectories passing on targets. The third-party/pjproject directory was created to house the pjproject source distribution. Its Makefile contains targets to download, patch configure, generate dependencies, compile libs, apps and python bindings, sanitized build.mak and generate a symbols list. When bootstrap.sh is run, it automatically includes the configure.m4 file in third-party/pjproject. This file has a macro to download and conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR and PJPROJECT_BUNDLED. It also tests for the capabilities like PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to trying to compile. Of course, bootstrap.sh is only run once and the configure file is incldued in the patch. When configure is run with the new options, the macro in configure.m4 triggers the download, patch, conifgure and tests. No compilation is performed at this time. The downloaded tarball is cached in /tmp so it doesn't get downloaded again on a distclean. When make is run in the top-level Asterisk source directory, it will automatically descend all the subdirectories in third_party just as it does for addons, apps, etc. The top-level Makefile makes sure that the 'third-party' is built before 'main' so that dependencies from the other directories are built first. When main does build, a new shared library (libasteriskpj) is created that links statically to the pjproject .a files and exports all their symbols. The asterisk binary links to that, just as it does with libasteriskssl. When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject python bindings are installed in ASTDATADIR/third-party/pjproject. This will facilitate testing, including running the testsuite which will be updated to check that directory for the pjsua module ahead of the system python library. Modules should continue to depend on pjproject if they use pjproject APIs directly. They should not care about the implementation. No changes to any res_pjsip modules were made. Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-19 03:54:28 +00:00
AC_DEFINE([HAVE_PJPROJECT], 1, [Define if your system has PJPROJECT])
AC_DEFINE([HAVE_PJPROJECT_BUNDLED], 1, [Define if your system has PJPROJECT_BUNDLED])
AC_DEFINE([HAVE_PJSIP_DLG_CREATE_UAS_AND_INC_LOCK], 1, [Define if your system has pjsip_dlg_create_uas_and_inc_lock declared.])
AC_DEFINE([HAVE_PJ_TRANSACTION_GRP_LOCK], 1, [Define if your system has pjsip_tsx_create_uac2 declared.])
AC_DEFINE([HAVE_PJSIP_REPLACE_MEDIA_STREAM], 1, [Define if your system has PJSIP_REPLACE_MEDIA_STREAM declared])
AC_DEFINE([HAVE_PJSIP_GET_DEST_INFO], 1, [Define if your system has pjsip_get_dest_info declared.])
AC_DEFINE([HAVE_PJ_SSL_CERT_LOAD_FROM_FILES2], 1, [Define if your system has pj_ssl_cert_load_from_files2 declared.])
AC_DEFINE([HAVE_PJSIP_EXTERNAL_RESOLVER], 1, [Define if your system has pjsip_endpt_set_ext_resolver declared.])
AC_DEFINE([HAVE_PJSIP_TLS_TRANSPORT_PROTO], 1, [Define if your system has PJSIP_TLS_TRANSPORT_PROTO])
res_pjsip_pubsub: Address SEGV when attempting to terminate a subscription Occasionally under load we'll attempt to send a final NOTIFY on a subscription that's already been terminated and a SEGV will occur down in pjproject's evsub_destroy function. This is a result of a race condition between all the paths that can generate a notify and/or destroy the underlying pjproject evsub object: * The client can send a SUBSCRIBE with Expires: 0. * The client can send a SUBSCRIBE/refresh. * The subscription timer can expire. * An extension state can change. * An MWI event can be generated. * The pjproject transaction timer (timer_b) can expire. Normally when our pubsub_on_evsub_state is called with a terminate, we push a task to the serializer and return at which point the dialog is unlocked. This is usually not a problem because the task runs immediately and locks the dialog again. When the system is heavily loaded though, there may be a delay between the unlock and relock during which another event may occur such as the subscription timer or timer_b expiring, an extension state change, etc. These may also cause a terminate to be processed and if so, we could cause pjproject to try to destroy the evsub structure twice. There's no way for us to tell that the evsub was already destroyed and the evsub's group lock can't tolerate this and SEGVs. The remedy is twofold. * A patch has been submitted to Teluu and added to the bundled pjproject which adds add/decrement operations on evsub's group lock. * In res_pjsip_pubsub: * configure.ac and pjproject-bundled's configure.m4 were updated to check for the new evsub group lock APIs. * We now add a reference to the evsub group lock when we create the subscription and remove the reference when we clean up the subscription. This prevents evsub from being destroyed before we're done with it. * A state has been added to the subscription tree structure so termination progress can be tracked through the asyncronous tasks. * The pubsub_on_evsub_state callback has been split so it's not doing double duty. It now only handles the final cleanup of the subscription tree. pubsub_on_rx_refresh now handles both client refreshes and client terminates. It was always being called for both anyway. * The serialized_on_server_timeout task was removed since serialized_pubsub_on_rx_refresh was almost identical. * Missing state checks and ao2_cleanups were added. * Some debug levels were adjusted to make seeing only off-nominal things at level 1 and nominal or progress things at level 2+. ASTERISK-26099 #close Reported-by: Ross Beer. Change-Id: I779d11802cf672a51392e62a74a1216596075ba1
2016-06-12 16:19:27 +00:00
AC_DEFINE([HAVE_PJSIP_EVSUB_GRP_LOCK], 1, [Define if your system has PJSIP_EVSUB_GRP_LOCK])
AC_DEFINE([HAVE_PJSIP_INV_SESSION_REF], 1, [Define if your system has PJSIP_INV_SESSION_REF])
AC_DEFINE([HAVE_PJSIP_AUTH_CLT_DEINIT], 1, [Define if your system has pjsip_auth_clt_deinit declared.])
res_pjsip_pubsub: Correctly implement persisted subscriptions This patch fixes 2 original issues and more that those 2 exposed. * When we send a NOTIFY, and the client either doesn't respond or responds with a non OK, pjproject only calls our pubsub_on_evsub_state callback, no others. Since pubsub_on_evsub_state (which does the sub_tree cleanup) does not expect to be called back without the other callbacks being called first, it just returns leaving the sub_tree orphaned. Now pubsub_on_evsub_state checks the event for PJSIP_EVENT_TSX_STATE which is what pjproject will set to tell us that it was the transaction that timed out or failed and not the subscription itself timing our or being terminated by the client. If is TSX_STATE, pubsub_on_evsub_state now does the proper cleanup regardless of the state of the subscription. * When a client renews a subscription, we don't update the persisted subscription with the new expires timestamp. This causes subscription_persistence_recreate to prune the subscription if/when asterisk restarts. Now, pubsub_on_rx_refresh calls subscription_persistence_update to apply the new expires timestamp. This exposed other issues however... * When creating a dialog from rdata (which sub_persistence_recreate does from the packet buffer) there must NOT be a tag on the To header (which there will be when a client refreshes a subscription). If there is one, pjsip_dlg_create_uas will fail. To address this, subscription_persistence_update now accepts a flag that indicates that the original packet buffer must not be updated. New subscribes don't set the flag and renews do. This makes sure that when the rdata is recreated on asterisk startup, it's done from the original subscribe packet which won't have the tag on To. * When creating a dialog from rdata, we were setting the dialog's remote (SUBSCRIBE) cseq to be the same as the local (NOTIFY) cseq. When the client tried to resubscribe after a restart with the correct cseq, we'd reject the request with an Invalid CSeq error. * The acts of creating a dialog and evsub by themselves when recreating a subscription does NOT restart pjproject's subscription timer. The result was that even if we did correctly recreate the subscription, we never removed it if the client happened to go away or send a non-OK response to a NOTIFY. However, there is no pjproject function exposed to just set the timer on an evsub that wasn't created by an incoming subscribe request. To address this, we create our own timer using ast_sip_schedule_task. This timer is used only for re-establishing subscriptions after a restart. An earlier approach was to add support for setting pjproject's timer (via a pjproject patch) and while that patch is still included here, we don't use that call at the moment. While addressing these issues, additional debugging was added and some existing messages made more useful. A few formatting changes were also made to 'pjsip show scheduled tasks' to make displaying the subscription timers a little more friendly. ASTERISK-26696 ASTERISK-26756 Change-Id: I8c605fc1e3923f466a74db087d5ab6f90abce68e
2017-02-07 19:17:12 +00:00
AC_DEFINE([HAVE_PJSIP_EVSUB_SET_UAS_TIMEOUT], 1, [Define if your system has pjsip_evsub_set_uas_timeout declared.])
AC_DEFINE([HAVE_PJSIP_TSX_LAYER_FIND_TSX2], 1, [Define if your system has pjsip_tsx_layer_find_tsx2 declared.])
AC_SUBST([PJPROJECT_BUNDLED])
AC_SUBST([PJPROJECT_DIR])
AC_SUBST([PBX_PJPROJECT])
AC_SUBST([PJPROJECT_LIB])
AC_SUBST([PJPROJECT_INCLUDE])
AC_MSG_RESULT(yes)
])
AC_DEFUN([PJPROJECT_CONFIGURE],
[
if test "$PJPROJECT_BUNDLED" = "yes" ; then
_PJPROJECT_CONFIGURE()
fi
build-system: Allow building with static pjproject Background here: http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html From CHANGES: * To help insure that Asterisk is compiled and run with the same known version of pjproject, a new option (--with-pjproject-bundled) has been added to ./configure. When specified, the version of pjproject specified in third-party/versions.mak will be downloaded and configured. When you make Asterisk, the build process will also automatically build pjproject and Asterisk will be statically linked to it. Once a particular version of pjproject is configured and built, it won't be configured or built again unless you run a 'make distclean'. To facilitate testing, when 'make install' is run, the pjsua and pjsystest utilities and the pjproject python bindings will be installed in ASTDATADIR/third-party/pjproject. The default behavior remains building with the shared pjproject installation, if any. Building: All you have to do is include the --with-pjproject-bundled option on the ./configure command line (and remove any existing --with-pjproject option if specified). Everything else is automatic. Behind the scenes: The top-level Makefile was modified to include 'third-party' in the list of MOD_SUBDIRS. The third-party directory was created to contain any third party packages that may be needed in the future. Its Makefile automatically iterates over any subdirectories passing on targets. The third-party/pjproject directory was created to house the pjproject source distribution. Its Makefile contains targets to download, patch configure, generate dependencies, compile libs, apps and python bindings, sanitized build.mak and generate a symbols list. When bootstrap.sh is run, it automatically includes the configure.m4 file in third-party/pjproject. This file has a macro to download and conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR and PJPROJECT_BUNDLED. It also tests for the capabilities like PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to trying to compile. Of course, bootstrap.sh is only run once and the configure file is incldued in the patch. When configure is run with the new options, the macro in configure.m4 triggers the download, patch, conifgure and tests. No compilation is performed at this time. The downloaded tarball is cached in /tmp so it doesn't get downloaded again on a distclean. When make is run in the top-level Asterisk source directory, it will automatically descend all the subdirectories in third_party just as it does for addons, apps, etc. The top-level Makefile makes sure that the 'third-party' is built before 'main' so that dependencies from the other directories are built first. When main does build, a new shared library (libasteriskpj) is created that links statically to the pjproject .a files and exports all their symbols. The asterisk binary links to that, just as it does with libasteriskssl. When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject python bindings are installed in ASTDATADIR/third-party/pjproject. This will facilitate testing, including running the testsuite which will be updated to check that directory for the pjsua module ahead of the system python library. Modules should continue to depend on pjproject if they use pjproject APIs directly. They should not care about the implementation. No changes to any res_pjsip modules were made. Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-19 03:54:28 +00:00
])