asterisk

Commit Graph

Author	SHA1	Message	Date
Jaco Kroon	44e5dd288b	Remove #include <sys/cdefs.h> These are not provided by standards, and as a result causes failure to compile on musl. https://wiki.musl-libc.org/faq.html#Q:-When-compiling-something-against-musl,-I-get-error-messages-about-%3Ccode%3Esys/cdefs.h%3C/code%3E Change-Id: I6a357cefd106c72cfecafd898638f6b5692c2e05	6 years ago
Sean Bright	fd0ca1c3f9	Remove as much trailing whitespace as possible. Change-Id: I873c1c6d00f447269bd841494459efccdd2c19c0	8 years ago
Terry Wilson	efd040cd11	Replace Berkeley DB with SQLite 3 There were some bugs in the very ancient version of Berkeley DB that Asterisk used. Instead of spending the time tracking down the bugs in the Berkeley code we move to the much better documented SQLite 3. Conversion of the old astdb happens at runtime by running the included astdb2sqlite3 utility. The ast_db API with SQLite 3 backend should behave identically to the old Berkeley backend, but in the future we could offer a much more robust interface. We do not include the SQLite 3 library in the source tree, but instead rely upon the distribution-provided libraries. SQLite is so ubiquitous that this should not place undue burden on administrators. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@326589 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago

Author

SHA1

Message

Date

Jaco Kroon

44e5dd288b

Remove #include <sys/cdefs.h>

These are not provided by standards, and as a result causes failure to
compile on musl.

https://wiki.musl-libc.org/faq.html#Q:-When-compiling-something-against-musl,-I-get-error-messages-about-%3Ccode%3Esys/cdefs.h%3C/code%3E

Change-Id: I6a357cefd106c72cfecafd898638f6b5692c2e05

Sean Bright

fd0ca1c3f9

Remove as much trailing whitespace as possible.

Change-Id: I873c1c6d00f447269bd841494459efccdd2c19c0

Terry Wilson

efd040cd11

Replace Berkeley DB with SQLite 3

There were some bugs in the very ancient version of Berkeley DB that Asterisk
used. Instead of spending the time tracking down the bugs in the Berkeley code
we move to the much better documented SQLite 3.

Conversion of the old astdb happens at runtime by running the included
astdb2sqlite3 utility. The ast_db API with SQLite 3 backend should behave
identically to the old Berkeley backend, but in the future we could offer a
much more robust interface.

We do not include the SQLite 3 library in the source tree, but instead rely
upon the distribution-provided libraries. SQLite is so ubiquitous that this
should not place undue burden on administrators.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@326589 65c4cc65-6c06-0410-ace0-fbb531ad65f3

3 Commits (10d4f2c45ff02b51a8f9c583c0386ae0d6a6e455)