don't include tonezone.h in dahdi_compat.h, because only a couple of modules need it
get app_rpt building again after the DAHDI changes
(closes issue #12911)
Reported by: tzafrir
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@125132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
may end up finding tds.h in /usr/local/include instead of /usr/include. If
this happens, the grep that looks for the version (from tdsver.h) will fail
and we'll have some problems during the build.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114695 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now if a directory is specified, then we will search that directory for
a source installation of the IMAP toolkit. If none is found, then we will
use that directory as the basis for detecting a package installation of
the IMAP c-client. If that check fails, then configure will fail.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103722 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now, if a source directory is specified with the --with-imap option, and a valid
source installation is not detected there, then configure will fail and will not
check for a package installation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103709 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk with IMAP support, you would use the --with-imap configure switch in one of the following
two ways:
--with-imap=/some/directory would look in the directory specified for a UW IMAP source installation
--with-imap would assume that you had imap-2004g installed in .. relative to the Asterisk source
With this set of changes the two above options still work the same, but there are two new behaviors, too.
--with-imap=system will assume that you have -libc-client.so where you store your shared objects and will
attempt to find c-client headers in your include path either in the imap or c-client directory.
If either of the two original methods of specifying the imap option should fail, then the check for --with-imap
=system will be performed in addition. It is only after this "system" check that failure can happen.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103698 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Normally, we would not backport features into 1.4, but, I was convinced by the
justification supplied by the supplier of this patch. He pointed out that this
patch removes a requirement for running as root, thus reducing the potential
impacts of security issues.
(closes issue #11742)
Reported by: paravoid
Patches:
libcap.diff uploaded by paravoid (license 200)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@98265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
rizzo brought up some issues related to the way that the metadata required
for menuselect and the rest of the build system is extracted from the source
files. Since I had a few hours to kill on an airplane today, I decided to
improve this situation... so now the system caches the extracted metadata
and uses it to build the menuselect 'tree' as much as it can. The result
of this is that when a single source file is changed, only the metadata for
that file needs to be extracted again, and the rest is used from the cache
files. I also reduced the number of forked processes required to do the
metadata extraction; it was actually possible to do most of what we needed
in the Makefiles themselves without using any shell scripts at all! On my
laptop, these changes resulted in an 80% decrease in the time required
for the 'menuselect.makeopts' automatic check to occur after editing a single
source file.
While doing this work I also cleaned up a few minor things in the Makefiles,
adding a check for 'awk' to the configure script and changed all remaining
places we use 'grep' or 'awk' to use the ones found by the configure script,
and changed the 'prep_tarball' script to build the menuselect metadata so
that tarballs of Asterisk will include it and won't require the user to
wait while it is extracted after unpacking.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@93180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
compiler is being used, then a warning will show up for any modules still using
the old name "private" instead of "_private".
(patch suggested by paravoid)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91032 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in the 1.2 version of libpri. This will prevent the configure script from thinking
that it has compatible libpri support for Asterisk 1.4, when it actually does not
because the installed version is from 1.2.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@74211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
simplify the handling e.g. in utils.c
Also add comments on a couple of features which are not working on FreeBSD.
All the above has been already done in trunk so the merge must be blocked.
Can someone please regenerate ./configure ?
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@72489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
still can't build *_odbc.so!", check for ltdl directly, instead of just listing
it as another library to include in the unixodbc check in the configure script.
This also makes ltdl show up as a dependency in menuselect so people know what
to go install. (related to issue #9989, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@69702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sure the results from curl-config can be used to compile successfully. This is
intended to help prevent a situation where you are cross compiling, and the
configure script finds the curl library installed on the host.
(issue #9865, reported and patched by zandbelt)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67026 65c4cc65-6c06-0410-ace0-fbb531ad65f3
