When FreeSWITCH is running as a non-privileged user, we need to enable
PR_SET_DUMPABLE for it to be able to generate core dumps.
Instead of a generic __linux__ check, there's a new configure.ac flag
to check directly for prctl.h, which could also be used in other
places in the code.
At least some versions of GCC appear to take any -Wno-foo option
without error even if that option is not supported. But they will
error out if -Wno-error=foo is used. This sounds like a GCC bug, but
we'll work around it and test for the feature both ways.
Thanks-to: Matteo Brancaleoni <mbrancaleoni@voismart.it>
FS-6850 #resolve
We're using -Wno-unused-result to work around what is arguably a GCC
bug, but this option is not supported on older GCC versions. So on
those versions we won't pass -Werror either.
ref: commit b874048efc
Modern static analyzers warn when a variable is set but not used. GCC
warns when the result of a function marked as
`__attribute__((warn_unused_result))` is not set to some variable,
even when the function is cast to `(void)`, which is the recognized
way of indicating the intent to ignore the result. We treat all
warnings as errors.
The combination of behaviors here makes it difficult if we really
don't care about the result of the function; the obvious workarounds
are precluded.
GCC's maintainers don't consider this to be a bug:
Why do you think this is a bug? warn_unused_result is for cases where
"not checking the result is either a security problem or always a
bug".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509#c1
GLIBC however marks functions like `read` and `write` with this
attribute. While it certainly in most cases is correct to act on
their return value, in some cases we really just don't care.
So when we see that we're building with GCC, and that we're building
with all warnings enabled, we'll just pass -Wno-unused-result to
disable the warning.
ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
ref: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Debian has packaged libpq version 9.4beta2. We were parsing the minor
version as "4beta2" and then trying to treat it as a constant integer,
which obviously doesn't work.
There's not really a perfect way to handle versions like this, so
we'll just pretend it's 9.4.0.
mod_prefix is an in-memory data store optimized for fast lookups
according to the longest prefix match (LPM) rule.
Tables of key-value string pairs in JSON format can be loaded at
startup via configuration and at runtime via the API.
The implementation uses a bitwise trie (aka binary prefix tree), so
arbitrary string keys are supported.
This removes our in-tree version of portaudio-19 and migrates
mod_portaudio and mod_portaudio_stream to use the system version of
the library. Our detection of the system library relies on
pkg-config.
Brian and I decided to handle this by just stripping -ansi -pedantic
from the mod_perl build instead.
Revert "Since we can't tell if the system perl was built with
pedantic, we have a problem because we default debug enabled which
uses AX_CFLAGS_WARN_ALL_ANSI, For the GNU CC compiler it will be
-Wall (and -ansi -pedantic) The result is added to the shellvar being
CFLAGS by default. Which then gets included for building mod_perl,
Either way I think this is the correct corse of action to overcome
these new builds of mod_perl."
This reverts commit cb94340e26.
Previously we would detect the missing LDNS system library at
configure time, but would only break during the build of mod_enum.
With this change, if mod_enum is enabled in modules.conf and the
system doesn't have a usable LDNS library we break during configure.
We depend on pkg-config, but we weren't explicitly testing for it, so
the absence of pkg-config would cause the sqlite test to fail, which
was confusing.
When the path was empty, path_push_unique would cause a training colon
to be added. This was a known issue that didn't cause any harm, but
while we're here, we'll clean this up.
sed on Mac is apparently incredibly broken and incapable of adding
newlines. `printf 'x' | sed 's/x/\n/'` results in 'n' on Mac rather
than a newline. GNU sed even in --posix mode does not agree with this
behavior. None the less, we can work around it here.
Some systems don't have the pkg-config file, or don't have it in the
right place. Breaking build on those systems does have the positive
effect of getting people to file bugs with those distros, but we
should at least keep things working on Debian wheezy while getting
Debian to accept the fix to ldns.
This library is used only by mod_enum and is available on most
platforms. The version in our tree has many code quality problems
that are generating noise when doing static analysis. Suffice it to
say we want rid of it as our responsibility.
FS-353
Tested with several libmemcached versions between 0.31 and
1.0.18. Unfortunately the API is extremely volatile and awkward to
use. Packaging scripts still need addressing.
FS-353
Since libedit originates from NetBSD, this and other BSDs use the
official version while Linux distributions tend to use the
autotoolized fork. The official version does not install a .pc file so
we cannot rely exclusively on pkg-config for detection.
FS-6408
Signed-off-by: Travis Cross <tc@traviscross.com>
Previously we enabled libedit support opportunistically if it was
neither enabled nor disabled explicitly. But this can result in
people being confused by libedit features not being available when
they really just need to install dependencies. With this change,
we'll break on configure if libedit-dev isn't there. If the user
really wants to build without libedit they just need to explicitly
disable it.
Cc: Ken Rice <krice@freeswitch.org>
We consider mod_spidermonkey to be completely replaced by mod_v8 (and
more generally by mod_lua) at this point. We've barely supported
mod_spidermonkey for years. Everyone should stop using it.
We're keeping this around for awhile in case people are relying on C
extensions to mod_spidermonkey and need time to migrate. This module
may or may not be part of a v1.4 release depending on whether we find
anyone cares. It definitely will not be part of the next release
after v1.4.
...at your own risk. cURL has had some serious security issues over
the years, so if you're using an ancient version, I hope that you're
receiving security patches from your vendor.
The version set here is to accommodate CentOS 6.
