2006-08-21 02:11:39 +00:00
|
|
|
#
|
2012-10-14 21:56:13 +00:00
|
|
|
# Asterisk -- An open source telephony toolkit.
|
2012-01-30 21:21:16 +00:00
|
|
|
#
|
2006-08-21 02:11:39 +00:00
|
|
|
# Makefile to build main Asterisk binary
|
|
|
|
|
#
|
|
|
|
|
# Copyright (C) 1999-2006, Digium, Inc.
|
|
|
|
|
#
|
|
|
|
|
# Mark Spencer <markster@digium.com>
|
|
|
|
|
#
|
|
|
|
|
# This program is free software, distributed under the terms of
|
|
|
|
|
# the GNU General Public License
|
|
|
|
|
#
|
|
|
|
|
|
2017-03-24 12:43:05 +00:00
|
|
|
-include $(ASTTOPDIR)/menuselect.makeopts $(ASTTOPDIR)/menuselect.makedeps $(ASTTOPDIR)/makeopts
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
|
all: asterisk
|
|
|
|
|
|
|
|
|
|
include $(ASTTOPDIR)/Makefile.moddir_rules
|
|
|
|
|
|
2018-02-17 03:11:42 +00:00
|
|
|
MOD_SRC:=cdr.c cel.c config.c ccss.c dnsmgr.c dsp.c enum.c features.c http.c indications.c logger.c manager.c named_acl.c plc.c sounds.c udptl.c
|
|
|
|
|
# Allow deletion of built-in modules without needing to modify this source.
|
|
|
|
|
MOD_SRC:=$(wildcard $(MOD_SRC))
|
2017-10-30 03:00:52 +00:00
|
|
|
MOD_OBJS:=$(sort $(MOD_SRC:.c=.o))
|
|
|
|
|
|
2010-01-13 18:16:13 +00:00
|
|
|
# Must include the extra ast_expr2.c, ast_expr2f.c, in case they need to be regenerated (because to force regeneration, we delete them)
|
2012-01-30 21:21:16 +00:00
|
|
|
SRC:=$(wildcard *.c) ast_expr2.c ast_expr2f.c
|
|
|
|
|
ifeq ($(AST_ASTERISKSSL),yes)
|
|
|
|
|
SRC:=$(filter-out libasteriskssl.c,$(SRC))
|
|
|
|
|
endif
|
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
|
|
|
ifeq ($(PJPROJECT_BUNDLED),yes)
|
|
|
|
|
SRC:=$(filter-out libasteriskpj.c,$(SRC))
|
|
|
|
|
endif
|
2017-10-30 03:00:52 +00:00
|
|
|
OBJSFILTER:=$(MOD_OBJS) fskmodem_int.o fskmodem_float.o cygload.o buildinfo.o
|
2009-05-29 19:46:07 +00:00
|
|
|
OBJS=$(filter-out $(OBJSFILTER),$(SRC:.c=.o))
|
2006-08-21 02:11:39 +00:00
|
|
|
|
|
|
|
|
# we need to link in the objects statically, not as a library, because
|
|
|
|
|
# otherwise modules will not have them available if none of the static
|
|
|
|
|
# objects use it.
|
|
|
|
|
OBJS+=stdtime/localtime.o
|
2012-01-30 21:21:16 +00:00
|
|
|
|
|
|
|
|
ASTSSL_LIBS:=$(OPENSSL_LIB)
|
|
|
|
|
AST_LIBS+=$(BKTR_LIB)
|
|
|
|
|
AST_LIBS+=$(LIBXML2_LIB)
|
2013-08-01 17:07:52 +00:00
|
|
|
AST_LIBS+=$(LIBXSLT_LIB)
|
2012-01-30 21:21:16 +00:00
|
|
|
AST_LIBS+=$(SQLITE3_LIB)
|
|
|
|
|
AST_LIBS+=$(ASTSSL_LIBS)
|
2013-01-11 22:31:42 +00:00
|
|
|
AST_LIBS+=$(JANSSON_LIB)
|
2013-08-23 21:49:47 +00:00
|
|
|
AST_LIBS+=$(URIPARSER_LIB)
|
2013-06-03 15:57:42 +00:00
|
|
|
AST_LIBS+=$(UUID_LIB)
|
2013-07-03 16:33:13 +00:00
|
|
|
AST_LIBS+=$(CRYPT_LIB)
|
2015-03-12 12:40:23 +00:00
|
|
|
AST_LIBS+=$(AST_CLANG_BLOCKS_LIBS)
|
2015-07-24 22:04:35 +00:00
|
|
|
AST_LIBS+=$(RT_LIB)
|
2016-06-27 19:26:54 +00:00
|
|
|
AST_LIBS+=$(SYSTEMD_LIB)
|
2008-07-28 19:53:56 +00:00
|
|
|
|
2016-06-03 05:59:30 +00:00
|
|
|
ifneq ($(findstring $(OSARCH), linux-gnu uclinux linux-uclibc linux-musl kfreebsd-gnu),)
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_LIBS+=-ldl
|
2006-09-27 21:48:01 +00:00
|
|
|
ifneq (x$(CAP_LIB),x)
|
|
|
|
|
AST_LIBS+=$(CAP_LIB)
|
|
|
|
|
endif
|
2018-03-22 10:43:18 +00:00
|
|
|
AST_LIBS+=-lpthread -lm -lresolv
|
2006-08-21 02:11:39 +00:00
|
|
|
else
|
2018-03-22 10:43:18 +00:00
|
|
|
AST_LIBS+=-lm
|
2006-08-21 02:11:39 +00:00
|
|
|
endif
|
|
|
|
|
|
2010-12-18 00:08:13 +00:00
|
|
|
ifneq ($(findstring BETTER_BACKTRACES,$(MENUSELECT_CFLAGS)),)
|
|
|
|
|
AST_LIBS+=$(BFD_LIB)
|
|
|
|
|
endif
|
|
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
ifneq ($(findstring darwin,$(OSARCH)),)
|
|
|
|
|
AST_LIBS+=-lresolv
|
2015-06-02 20:07:08 +00:00
|
|
|
ASTLINK=-mmacosx-version-min=10.6 -Wl,-undefined,dynamic_lookup -force_flat_namespace
|
2013-01-18 22:42:38 +00:00
|
|
|
ASTLINK+=/usr/lib/bundle1.o
|
2006-08-21 02:11:39 +00:00
|
|
|
else
|
|
|
|
|
# These are used for all but Darwin
|
2017-03-24 12:43:05 +00:00
|
|
|
ASTLINK+=-Wl,--export-dynamic
|
2006-08-21 02:11:39 +00:00
|
|
|
ifneq ($(findstring BSD,$(OSARCH)),)
|
|
|
|
|
LDFLAGS+=-L/usr/local/lib
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(OSARCH),FreeBSD)
|
2007-11-05 21:27:04 +00:00
|
|
|
# -V is understood by BSD Make, not by GNU make.
|
|
|
|
|
BSDVERSION=$(shell make -V OSVERSION -f /usr/share/mk/bsd.port.subdir.mk)
|
|
|
|
|
AST_LIBS+=$(shell if test $(BSDVERSION) -lt 502102 ; then echo "-lc_r"; else echo "-pthread"; fi)
|
2006-08-21 02:11:39 +00:00
|
|
|
AST_LIBS+=-lcrypto
|
|
|
|
|
endif
|
|
|
|
|
|
2007-11-17 10:54:52 +00:00
|
|
|
ifneq ($(findstring $(OSARCH), mingw32 cygwin ),)
|
|
|
|
|
AST_LIBS+=-lminires -ldl
|
2012-01-30 21:21:16 +00:00
|
|
|
ASTLINK+=-shared -Wl,--out-implib,libasterisk.a
|
2007-11-17 10:54:52 +00:00
|
|
|
endif
|
2006-08-21 02:11:39 +00:00
|
|
|
ifeq ($(OSARCH),NetBSD)
|
2018-03-22 10:43:18 +00:00
|
|
|
AST_LIBS+=-lpthread -lcrypto -lm -L/usr/pkg/lib
|
2006-08-21 02:11:39 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(OSARCH),OpenBSD)
|
2018-03-22 10:43:18 +00:00
|
|
|
AST_LIBS+=-lcrypto -lpthread -lm
|
2006-08-21 02:11:39 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(OSARCH),SunOS)
|
2012-01-30 21:21:16 +00:00
|
|
|
AST_LIBS+=-lpthread -ldl -lrt -lnsl -lsocket -lresolv
|
|
|
|
|
ASTSSL_LIBS+=-L/opt/ssl/lib -L/usr/local/ssl/lib
|
2006-08-21 02:11:39 +00:00
|
|
|
ASTLINK=
|
|
|
|
|
endif
|
|
|
|
|
|
2008-08-03 16:14:14 +00:00
|
|
|
ifneq ($(findstring USE_HOARD_ALLOCATOR,$(MENUSELECT_CFLAGS)),)
|
|
|
|
|
ifneq ($(HOARD_LIB),)
|
|
|
|
|
AST_LIBS+=$(HOARD_LIB)
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
2009-03-18 02:21:23 +00:00
|
|
|
ifeq ($(GNU_LD),1)
|
2010-07-16 04:45:33 +00:00
|
|
|
ASTLINK+=-Wl,--version-script,asterisk.exports
|
|
|
|
|
ifeq ($(HAVE_DYNAMIC_LIST),1)
|
|
|
|
|
ASTLINK+=-Wl,--dynamic-list,asterisk.dynamics
|
|
|
|
|
endif
|
2009-03-18 02:21:23 +00:00
|
|
|
endif
|
|
|
|
|
|
2011-08-03 15:16:25 +00:00
|
|
|
.PHONY: CHECK_SUBDIR
|
2007-06-29 20:33:35 +00:00
|
|
|
CHECK_SUBDIR: # do nothing, just make sure that we recurse in the subdir/
|
|
|
|
|
|
2010-01-25 21:51:41 +00:00
|
|
|
ifneq ($(findstring REBUILD_PARSERS,$(MENUSELECT_CFLAGS)),)
|
2010-01-25 05:30:33 +00:00
|
|
|
ast_expr2.c ast_expr2.h: ast_expr2.y
|
|
|
|
|
else
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_expr2.c ast_expr2.h:
|
2010-01-25 05:30:33 +00:00
|
|
|
endif
|
|
|
|
|
$(ECHO_PREFIX) echo " [BISON] $< -> $@"
|
2010-01-25 05:45:00 +00:00
|
|
|
$(CMD_PREFIX) $(BISON) -o $@ -d --name-prefix=ast_yy ast_expr2.y
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2010-01-25 21:51:41 +00:00
|
|
|
ifneq ($(findstring REBUILD_PARSERS,$(MENUSELECT_CFLAGS)),)
|
2010-01-25 05:30:33 +00:00
|
|
|
ast_expr2f.c: ast_expr2.fl
|
|
|
|
|
else
|
2006-08-21 02:11:39 +00:00
|
|
|
ast_expr2f.c:
|
2010-01-25 05:30:33 +00:00
|
|
|
endif
|
|
|
|
|
$(ECHO_PREFIX) echo " [FLEX] $< -> $@"
|
2018-04-18 20:40:56 +00:00
|
|
|
$(CMD_PREFIX) echo "#define ASTMM_LIBC ASTMM_REDIRECT" > $@
|
|
|
|
|
$(CMD_PREFIX) echo "#include \"asterisk.h\"" >> $@
|
2010-01-25 05:30:33 +00:00
|
|
|
$(CMD_PREFIX) echo >> $@
|
2023-03-21 13:24:59 +00:00
|
|
|
$(CMD_PREFIX) $(FLEX) -t ast_expr2.fl >> $@
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2018-08-01 04:54:11 +00:00
|
|
|
ifneq ($(findstring ENABLE_UPLOADS,$(MENUSELECT_CFLAGS)),)
|
|
|
|
|
GMIMELDFLAGS+=$(GMIME_LIB)
|
|
|
|
|
GMIMECFLAGS+=$(GMIME_INCLUDE)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# Alter CFLAGS for specific sources
|
|
|
|
|
stdtime/localtime.o: _ASTCFLAGS+=$(AST_NO_STRICT_OVERFLOW) -Wno-format-nonliteral
|
2008-03-11 11:36:51 +00:00
|
|
|
|
2012-07-25 12:21:54 +00:00
|
|
|
asterisk.o: _ASTCFLAGS+=$(LIBEDIT_INCLUDE)
|
2018-08-01 04:54:11 +00:00
|
|
|
ast_expr2f.o: _ASTCFLAGS+=-Wno-unused
|
|
|
|
|
astmm.o: _ASTCFLAGS+=$(call get_menuselect_cflags,MALLOC_DEBUG DEBUG_CHAOS)
|
|
|
|
|
astobj2.o astobj2_container.o astobj2_hash.o astobj2_rbtree.o: _ASTCFLAGS+=$(call get_menuselect_cflags,AO2_DEBUG)
|
|
|
|
|
backtrace.o: _ASTCFLAGS+=$(call get_menuselect_cflags,BETTER_BACKTRACES)
|
2013-08-23 21:49:47 +00:00
|
|
|
bucket.o: _ASTCFLAGS+=$(URIPARSER_INCLUDE)
|
2018-08-01 04:54:11 +00:00
|
|
|
cdr.o: _ASTCFLAGS+=$(AST_NO_FORMAT_TRUNCATION)
|
2013-07-04 13:06:15 +00:00
|
|
|
crypt.o: _ASTCFLAGS+=$(CRYPT_INCLUDE)
|
2018-08-01 04:54:11 +00:00
|
|
|
db.o: _ASTCFLAGS+=$(SQLITE3_INCLUDE)
|
|
|
|
|
dsp.o: _ASTCFLAGS+=$(call get_menuselect_cflags,RADIO_RELAX)
|
2019-11-08 15:20:13 +00:00
|
|
|
frame.o: _ASTCFLAGS+=$(call get_menuselect_cflags,MALLOC_DEBUG)
|
2018-08-01 04:54:11 +00:00
|
|
|
http.o: _ASTCFLAGS+=$(GMIMECFLAGS)
|
|
|
|
|
iostream.o: _ASTCFLAGS+=$(OPENSSL_INCLUDE)
|
|
|
|
|
json.o: _ASTCFLAGS+=$(JANSSON_INCLUDE)
|
|
|
|
|
lock.o: _ASTCFLAGS+=$(call get_menuselect_cflags,DETECT_DEADLOCKS)
|
|
|
|
|
options.o: _ASTCFLAGS+=$(call get_menuselect_cflags,REF_DEBUG)
|
|
|
|
|
sched.o: _ASTCFLAGS+=$(call get_menuselect_cflags,DEBUG_SCHEDULER DUMP_SCHEDULER)
|
|
|
|
|
tcptls.o: _ASTCFLAGS+=$(OPENSSL_INCLUDE) -Wno-deprecated-declarations
|
2022-05-03 04:49:54 +00:00
|
|
|
# since we're using open_memstream(), we need to release the buffer with
|
|
|
|
|
# the native free() function or we might get unexpected behavior.
|
|
|
|
|
test.o: _ASTCFLAGS+=-DASTMM_LIBC=ASTMM_IGNORE
|
2013-06-03 15:57:42 +00:00
|
|
|
uuid.o: _ASTCFLAGS+=$(UUID_INCLUDE)
|
2018-09-19 19:34:41 +00:00
|
|
|
stasis.o: _ASTCFLAGS+=$(call get_menuselect_cflags,AO2_DEBUG)
|
2022-02-13 19:06:37 +00:00
|
|
|
time.o: _ASTCFLAGS+=-D_XOPEN_SOURCE=700
|
2011-07-06 20:58:12 +00:00
|
|
|
|
2008-03-11 11:36:51 +00:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
OBJS:=$(sort $(OBJS))
|
|
|
|
|
|
2007-11-17 12:33:15 +00:00
|
|
|
ifneq ($(findstring $(OSARCH), mingw32 cygwin ),)
|
|
|
|
|
MAIN_TGT:=asterisk.dll
|
|
|
|
|
asterisk: cygload
|
|
|
|
|
mv cygload.exe asterisk.exe
|
|
|
|
|
|
|
|
|
|
cygload: asterisk.dll
|
|
|
|
|
else
|
|
|
|
|
MAIN_TGT:=asterisk
|
|
|
|
|
endif
|
|
|
|
|
|
2015-03-30 11:43:19 +00:00
|
|
|
$(OBJS): _ASTCFLAGS+=-DAST_MODULE=\"core\" -DAST_IN_CORE
|
2017-10-30 03:00:52 +00:00
|
|
|
$(MOD_OBJS): _ASTCFLAGS+=$(call MOD_ASTCFLAGS,$*)
|
2010-03-23 14:22:27 +00:00
|
|
|
|
2012-09-12 14:22:54 +00:00
|
|
|
libasteriskssl.o: _ASTCFLAGS+=$(OPENSSL_INCLUDE)
|
|
|
|
|
|
2012-01-30 21:21:16 +00:00
|
|
|
ifeq ($(AST_ASTERISKSSL),yes)
|
|
|
|
|
# The ABI *version* of the asteriskssl library; don't change this unless there truly is a
|
|
|
|
|
# non-backwards-compatible ABI change in the library
|
|
|
|
|
ASTSSL_SO_VERSION=1
|
|
|
|
|
|
|
|
|
|
ASTSSL_LDLIBS=-L. -lasteriskssl
|
|
|
|
|
|
|
|
|
|
ifeq ($(findstring darwin,$(OSARCH)),) # not Darwin
|
|
|
|
|
ASTSSL_LIB:=libasteriskssl.so
|
|
|
|
|
|
2017-01-23 15:35:38 +00:00
|
|
|
$(ASTSSL_LIB).$(ASTSSL_SO_VERSION): _ASTLDFLAGS+=-Wl,-soname=$(ASTSSL_LIB).$(ASTSSL_SO_VERSION)
|
2015-05-04 19:26:37 +00:00
|
|
|
$(ASTSSL_LIB).$(ASTSSL_SO_VERSION): _ASTCFLAGS+=-fPIC -DAST_MODULE=\"asteriskssl\" -DAST_NOT_MODULE
|
2012-01-30 21:21:16 +00:00
|
|
|
$(ASTSSL_LIB).$(ASTSSL_SO_VERSION): LIBS+=$(ASTSSL_LIBS)
|
2014-04-17 20:25:16 +00:00
|
|
|
ifeq ($(GNU_LD),1)
|
|
|
|
|
$(ASTSSL_LIB).$(ASTSSL_SO_VERSION): SO_SUPPRESS_SYMBOLS=-Wl,--version-script,libasteriskssl.exports,--warn-common
|
|
|
|
|
endif
|
2012-01-30 21:21:16 +00:00
|
|
|
$(ASTSSL_LIB).$(ASTSSL_SO_VERSION): SOLINK=$(DYLINK)
|
|
|
|
|
|
|
|
|
|
# These rules are duplicated from $(ASTTOPDIR)/Makefile.rules because the library name
|
|
|
|
|
# being built does not match the "%.so" pattern; there are also additional steps
|
|
|
|
|
# required to build a proper shared library (as opposed to the 'loadable module'
|
|
|
|
|
# type that are built by the standard rules)
|
|
|
|
|
$(ASTSSL_LIB).$(ASTSSL_SO_VERSION): libasteriskssl.o
|
|
|
|
|
ifeq ($(GNU_LD),1)
|
|
|
|
|
$(CMD_PREFIX) $(ASTTOPDIR)/build_tools/make_linker_version_script libasteriskssl "$(LINKER_SYMBOL_PREFIX)" "$(ASTTOPDIR)"
|
|
|
|
|
endif
|
|
|
|
|
$(ECHO_PREFIX) echo " [LD] $^ -> $@"
|
2018-07-17 10:24:02 +00:00
|
|
|
$(CMD_PREFIX) $(CC) -o $@ $(CC_LDFLAGS_SO) $^ $(CC_LIBS)
|
2012-01-30 21:21:16 +00:00
|
|
|
|
|
|
|
|
$(ASTSSL_LIB): $(ASTSSL_LIB).$(ASTSSL_SO_VERSION)
|
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
|
|
|
$(ECHO_PREFIX) echo " [LN] $< -> $@"
|
2016-04-30 22:52:47 +00:00
|
|
|
$(LN) -sf $< $@ ;\
|
2012-01-30 21:21:16 +00:00
|
|
|
|
|
|
|
|
else # Darwin
|
|
|
|
|
ASTSSL_LIB:=libasteriskssl.dylib
|
|
|
|
|
|
2013-01-18 21:35:09 +00:00
|
|
|
# -install_name allows library to be found if installed somewhere other than
|
|
|
|
|
# /lib or /usr/lib
|
|
|
|
|
$(ASTSSL_LIB): _ASTLDFLAGS+=-dynamiclib -install_name $(ASTLIBDIR)/$(ASTSSL_LIB)
|
2016-08-11 15:50:09 +00:00
|
|
|
$(ASTSSL_LIB): _ASTCFLAGS+=-fPIC -DAST_MODULE=\"asteriskssl\" -DAST_NOT_MODULE
|
2012-01-30 21:21:16 +00:00
|
|
|
$(ASTSSL_LIB): LIBS+=$(ASTSSL_LIBS)
|
|
|
|
|
$(ASTSSL_LIB): SOLINK=$(DYLINK)
|
|
|
|
|
|
|
|
|
|
# Special rules for building a shared library (not a dynamically loadable module)
|
|
|
|
|
$(ASTSSL_LIB): libasteriskssl.o
|
|
|
|
|
$(ECHO_PREFIX) echo " [LD] $^ -> $@"
|
2018-07-17 10:24:02 +00:00
|
|
|
$(CMD_PREFIX) $(CC) -o $@ $(CC_LDFLAGS_SO) $^ $(CC_LIBS)
|
2012-01-30 21:21:16 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
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
|
|
|
libasteriskpj.o: _ASTCFLAGS+=$(PJPROJECT_INCLUDE)
|
|
|
|
|
|
|
|
|
|
ifeq ($(PJPROJECT_BUNDLED),yes)
|
|
|
|
|
|
|
|
|
|
ASTPJ_SO_VERSION=2
|
|
|
|
|
ASTPJ_LDLIBS=-L. -lasteriskpj
|
|
|
|
|
|
2016-10-28 21:59:19 +00:00
|
|
|
PJDIR=$(ASTTOPDIR)/$(PJPROJECT_DIR)/source
|
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
|
|
|
-include $(ASTTOPDIR)/$(PJPROJECT_DIR)/build.mak
|
|
|
|
|
|
|
|
|
|
PJPROJECT_LDLIBS := \
|
|
|
|
|
-Wl,--whole-archive \
|
|
|
|
|
$(PJSUA_LIB_LDLIB) \
|
|
|
|
|
$(PJSIP_UA_LDLIB) \
|
|
|
|
|
$(PJSIP_SIMPLE_LDLIB) \
|
|
|
|
|
$(PJSIP_LDLIB) \
|
|
|
|
|
$(PJNATH_LDLIB) \
|
|
|
|
|
$(PJMEDIA_CODEC_LDLIB) \
|
|
|
|
|
$(PJMEDIA_VIDEODEV_LDLIB) \
|
|
|
|
|
$(PJMEDIA_AUDIODEV_LDLIB) \
|
|
|
|
|
$(PJMEDIA_LDLIB) \
|
|
|
|
|
$(PJLIB_UTIL_LDLIB) \
|
|
|
|
|
$(PJLIB_LDLIB) \
|
|
|
|
|
-Wl,--no-whole-archive \
|
|
|
|
|
$(APP_THIRD_PARTY_LIBS) \
|
|
|
|
|
$(APP_THIRD_PARTY_EXT)
|
|
|
|
|
|
|
|
|
|
ifeq ($(findstring darwin,$(OSARCH)),) # not Darwin
|
|
|
|
|
ASTPJ_LIB:=libasteriskpj.so
|
|
|
|
|
|
|
|
|
|
libasteriskpj.exports: $(ASTTOPDIR)/$(PJPROJECT_DIR)/pjproject.symbols
|
|
|
|
|
$(ECHO_PREFIX) echo " [GENERATE] libasteriskpj.exports"
|
|
|
|
|
ifeq ($(GNU_LD),1)
|
2016-11-17 02:24:08 +00:00
|
|
|
$(CMD_PREFIX) echo -e "{\nglobal:" > libasteriskpj.exports
|
|
|
|
|
$(CMD_PREFIX) sed -r -e "s/.*/$(LINKER_SYMBOL_PREFIX)&;/" $(ASTTOPDIR)/$(PJPROJECT_DIR)/pjproject.symbols >> libasteriskpj.exports
|
|
|
|
|
$(CMD_PREFIX) echo -e "$(LINKER_SYMBOL_PREFIX)ast_pj_init;\n" >> libasteriskpj.exports
|
|
|
|
|
$(CMD_PREFIX) echo -e "local:\n*;\n};" >> libasteriskpj.exports
|
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
|
|
|
endif
|
|
|
|
|
|
2017-01-23 15:35:38 +00:00
|
|
|
$(ASTPJ_LIB).$(ASTPJ_SO_VERSION): _ASTLDFLAGS+=-Wl,-soname=$(ASTPJ_LIB).$(ASTPJ_SO_VERSION) $(PJ_LDFLAGS)
|
2016-08-09 00:14:20 +00:00
|
|
|
$(ASTPJ_LIB).$(ASTPJ_SO_VERSION): _ASTCFLAGS+=-fPIC -DAST_MODULE=\"asteriskpj\" -DAST_NOT_MODULE $(PJ_CFLAGS)
|
2017-11-19 19:52:59 +00:00
|
|
|
$(ASTPJ_LIB).$(ASTPJ_SO_VERSION): LIBS+=$(PJPROJECT_LDLIBS) $(OPENSSL_LIB) $(UUID_LIB) -lm -lpthread $(RT_LIB)
|
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
|
|
|
ifeq ($(GNU_LD),1)
|
|
|
|
|
$(ASTPJ_LIB).$(ASTPJ_SO_VERSION): SO_SUPPRESS_SYMBOLS=-Wl,--version-script,libasteriskpj.exports,--warn-common
|
|
|
|
|
endif
|
|
|
|
|
$(ASTPJ_LIB).$(ASTPJ_SO_VERSION): SOLINK=$(DYLINK)
|
|
|
|
|
|
|
|
|
|
# These rules are duplicated from $(ASTTOPDIR)/Makefile.rules because the library name
|
|
|
|
|
# being built does not match the "%.so" pattern; there are also additional steps
|
|
|
|
|
# required to build a proper shared library (as opposed to the 'loadable module'
|
|
|
|
|
# type that are built by the standard rules)
|
|
|
|
|
$(ASTPJ_LIB).$(ASTPJ_SO_VERSION): libasteriskpj.o libasteriskpj.exports
|
|
|
|
|
$(ECHO_PREFIX) echo " [LD] $< -> $@"
|
2018-07-17 10:24:02 +00:00
|
|
|
$(CMD_PREFIX) $(CC) -o $@ $(CC_LDFLAGS_SO) $< $(CC_LIBS)
|
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
|
|
|
|
|
|
|
|
$(ASTPJ_LIB): $(ASTPJ_LIB).$(ASTPJ_SO_VERSION)
|
|
|
|
|
$(ECHO_PREFIX) echo " [LN] $< -> $@"
|
2016-04-30 22:52:47 +00:00
|
|
|
$(LN) -sf $< $@ ;\
|
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
|
|
|
|
|
|
|
|
else # Darwin
|
|
|
|
|
ASTPJ_LIB:=libasteriskpj.dylib
|
|
|
|
|
|
|
|
|
|
# -install_name allows library to be found if installed somewhere other than
|
|
|
|
|
# /lib or /usr/lib
|
|
|
|
|
$(ASTPJ_LIB): _ASTLDFLAGS+=-dynamiclib -install_name $(ASTLIBDIR)/$(ASTPJ_LIB) $(PJ_LDFLAGS)
|
2016-08-11 15:50:09 +00:00
|
|
|
$(ASTPJ_LIB): _ASTCFLAGS+=-fPIC -DAST_MODULE=\"asteriskpj\" $(PJ_CFLAGS) -DAST_NOT_MODULE
|
2018-03-08 11:28:37 +00:00
|
|
|
$(ASTPJ_LIB): LIBS+=$(PJPROJECT_LIB) $(OPENSSL_LIB) $(UUID_LIB) -lm -lpthread $(RT_LIB)
|
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
|
|
|
$(ASTPJ_LIB): SOLINK=$(DYLINK)
|
|
|
|
|
|
|
|
|
|
# Special rules for building a shared library (not a dynamically loadable module)
|
|
|
|
|
$(ASTPJ_LIB): libasteriskpj.o
|
|
|
|
|
$(ECHO_PREFIX) echo " [LD] $^ -> $@"
|
2018-07-17 10:24:02 +00:00
|
|
|
$(CMD_PREFIX) $(CC) -o $@ $(CC_LDFLAGS_SO) $^ $(CC_LIBS)
|
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
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
2018-02-12 07:26:56 +00:00
|
|
|
$(MAIN_TGT): $(OBJS) $(MOD_OBJS) $(ASTSSL_LIB) $(ASTPJ_LIB)
|
2009-07-21 13:28:04 +00:00
|
|
|
@$(CC) -c -o buildinfo.o $(_ASTCFLAGS) buildinfo.c $(ASTCFLAGS)
|
2018-02-12 07:26:56 +00:00
|
|
|
$(ECHO_PREFIX) echo " [LD] $(OBJS) $(MOD_OBJS) -> $@"
|
2018-07-17 10:24:02 +00:00
|
|
|
$(CMD_PREFIX) $(CXX) -o $@ $(ASTLINK) $(_ASTLDFLAGS) $(ASTLDFLAGS) $(OBJS) $(MOD_OBJS) $(ASTSSL_LDLIBS) $(ASTPJ_LDLIBS) buildinfo.o $(AST_LIBS) $(GMIMELDFLAGS) $(LIBEDIT_LIB)
|
2006-08-21 02:11:39 +00:00
|
|
|
|
2010-04-02 18:57:58 +00:00
|
|
|
ifeq ($(GNU_LD),1)
|
|
|
|
|
$(MAIN_TGT): asterisk.exports
|
|
|
|
|
asterisk.exports: asterisk.exports.in
|
|
|
|
|
$(CMD_PREFIX) $(ASTTOPDIR)/build_tools/make_linker_version_script asterisk $(LINKER_SYMBOL_PREFIX)
|
|
|
|
|
endif
|
|
|
|
|
|
2012-01-30 21:21:16 +00:00
|
|
|
bininstall:
|
|
|
|
|
$(INSTALL) -m 755 $(MAIN_TGT) "$(DESTDIR)$(ASTSBINDIR)/"
|
|
|
|
|
ifeq ($(AST_ASTERISKSSL),yes)
|
2012-09-12 14:22:54 +00:00
|
|
|
ifeq ($(findstring darwin,$(OSARCH)),) # not Darwin
|
2012-01-30 21:21:16 +00:00
|
|
|
$(INSTALL) -m 755 $(ASTSSL_LIB).$(ASTSSL_SO_VERSION) "$(DESTDIR)$(ASTLIBDIR)/"
|
2012-12-17 20:59:51 +00:00
|
|
|
$(LN) -sf $(ASTSSL_LIB).$(ASTSSL_SO_VERSION) "$(DESTDIR)$(ASTLIBDIR)/$(ASTSSL_LIB)"
|
2012-09-12 14:22:54 +00:00
|
|
|
else # Darwin
|
|
|
|
|
$(INSTALL) -m 755 $(ASTSSL_LIB) "$(DESTDIR)$(ASTLIBDIR)/"
|
|
|
|
|
endif
|
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
|
|
|
endif
|
|
|
|
|
ifeq ($(PJPROJECT_BUNDLED),yes)
|
|
|
|
|
ifeq ($(findstring darwin,$(OSARCH)),) # not Darwin
|
|
|
|
|
$(INSTALL) -m 755 $(ASTPJ_LIB).$(ASTPJ_SO_VERSION) "$(DESTDIR)$(ASTLIBDIR)/"
|
|
|
|
|
$(LN) -sf $(ASTPJ_LIB).$(ASTPJ_SO_VERSION) "$(DESTDIR)$(ASTLIBDIR)/$(ASTPJ_LIB)"
|
|
|
|
|
else # Darwin
|
|
|
|
|
$(INSTALL) -m 755 $(ASTPJ_LIB) "$(DESTDIR)$(ASTLIBDIR)/"
|
|
|
|
|
endif
|
2012-01-30 21:21:16 +00:00
|
|
|
endif
|
|
|
|
|
$(LN) -sf asterisk "$(DESTDIR)$(ASTSBINDIR)/rasterisk"
|
|
|
|
|
|
|
|
|
|
binuninstall:
|
|
|
|
|
rm -f "$(DESTDIR)$(ASTSBINDIR)/$(MAIN_TGT)"
|
|
|
|
|
rm -f "$(DESTDIR)$(ASTSBINDIR)/rasterisk"
|
2017-02-27 18:25:01 +00:00
|
|
|
rm -f "$(DESTDIR)$(ASTLIBDIR)/libasterisk"* || :
|
2017-03-28 18:01:16 +00:00
|
|
|
test -n "$(_oldlibdir)" -a -d "$(_oldlibdir)" && rm -f "$(_oldlibdir)/libasterisk"* || :
|
2012-01-30 21:21:16 +00:00
|
|
|
|
2006-08-21 02:11:39 +00:00
|
|
|
clean::
|
2012-09-13 20:05:54 +00:00
|
|
|
rm -f asterisk libasteriskssl.o
|
|
|
|
|
ifeq ($(AST_ASTERISKSSL),yes)
|
|
|
|
|
rm -f $(ASTSSL_LIB) $(ASTSSL_LIB).*
|
|
|
|
|
endif
|
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
|
|
|
rm -f libasteriskpj.o
|
|
|
|
|
rm -f libasteriskpj.so* libasteriskpj.dynlib
|
|
|
|
|
rm -f .libasteriskpj*
|
|
|
|
|
|
|
|
|
|
rm -f asterisk.exports libasteriskssl.exports libasteriskpj.exports
|
2006-08-21 02:11:39 +00:00
|
|
|
@$(MAKE) -C stdtime clean
|
2008-01-02 16:20:26 +00:00
|
|
|
rm -f libresample/src/*.o
|
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
|
|
|
rm -f *.tmp
|
