aboutsummaryrefslogtreecommitdiff
path: root/src/common/include.am
Commit message (Collapse)AuthorAge
* Basic backtrace abilityNick Mathewson2013-11-18
| | | | | | On platforms with the backtrace/backtrace_symbols_fd interface, Tor can now dump stack traces on assertion failure. By default, I log them to DataDir/stack_dump and to stderr.
* Merge remote-tracking branch 'public/fancy_test_tricks'Nick Mathewson2013-07-15
|\ | | | | | | | | | | | | | | Conflicts: src/common/include.am Conflict was from adding testsupport.h near where sandbox.h had already been added.
| * Coverage support: build with --enable-coverage to have tests run with gcovNick Mathewson2013-07-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you pass the --enable-coverage flag on the command line, we build our testing binaries with appropriate options eo enable coverage testing. We also build a "tor-cov" binary that has coverage enabled, for integration tests. On recent OSX versions, test coverage only works with clang, not gcc. So we warn about that. Also add a contrib/coverage script to actually run gcov with the appropriate options to generate useful .gcov files. (Thanks to automake, the .o files will not have the names that gcov expects to find.) Also, remove generated gcda and gcno files on clean.
| * Start work on fancy compiler tricks to expose extra stuff to our testsNick Mathewson2013-07-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is mainly a matter of automake trickery: we build each static library in two versions now: one with the TOR_UNIT_TESTS macro defined, and one without. When TOR_UNIT_TESTS is defined, we can enable mocking and expose more functions. When it's not defined, we can lock the binary down more. The alternatives would be to have alternate build modes: a "testing configuration" for building the libraries with test support, and a "production configuration" for building them without. I don't favor that approach, since I think it would mean more people runnning binaries build for testing, or more people not running unit tests.
* | cosmetic cleanupsRoger Dingledine2013-07-14
| |
* | put sandbox.h in the tarball, so the tarball buildsRoger Dingledine2013-07-13
| |
* | Add a basic seccomp2 syscall filter on LinuxCristian Toader2013-07-11
|/ | | | | It's controlled by the new Sandbox argument. Right now, it's rather coarse-grained, it's Linux-only, and it may break some features.
* Merge remote-tracking branch 'public/feature8109'Nick Mathewson2013-03-01
|\
| * Build donna32 with -fomit-frame-pointerNick Mathewson2013-01-30
| |
* | Fix compilation with --disable-curve25519 optionNick Mathewson2013-02-04
|/ | | | | | | | | The fix is to move the two functions to format/parse base64 curve25519 public keys into a new "crypto_format.c" file. I could have put them in crypto.c, but that's a big file worth splitting anyway. Fixes bug 8153; bugfix on 0.2.4.8-alpha where I did the fix for 7869.
* Make libcurve25519_donna get built as a .aNick Mathewson2013-01-03
| | | | | This lets us give it compiler flags differing from the rest of libor-crypto.a
* Add a wrapper around, and test and build support for, curve25519.Nick Mathewson2013-01-02
| | | | | | | | | | | | | | | | | | We want to use donna-c64 when we have a GCC with support for 64x64->uint128_t multiplying. If not, we want to use libnacl if we can, unless it's giving us the unsafe "ref" implementation. And if that isn't going to work, we'd like to use the portable-and-safe-but-slow 32-bit "donna" implementation. We might need more library searching for the correct libnacl, especially once the next libnacl release is out -- it's likely to have bunches of better curve25519 implementations. I also define a set of curve25519 wrapper functions, though it really shouldn't be necessary. We should eventually make the -donna*.c files get build with -fomit-frame-pointer, since that can make a difference.
* Move strlcpy and strlcat into src/ext tooNick Mathewson2012-10-12
|
* Move all externally maintained source files into src/extNick Mathewson2012-10-11
| | | | | | The rationale for treating these files differently is that we should be checking upstream for changes as applicable, and merging changes upstream as warranted.
* Drop support for openssl 0.9.7Nick Mathewson2012-09-12
| | | | | | | 097 hasn't seen a new version since 2007; we can drop support too. This lets us remove our built-in sha256 implementation, and some checks for old bugs.
* Fix a dependency: sha256.c influences crypto.o, not crypto.cNick Mathewson2012-09-06
|
* Fix a build-warning when building out-of-treeNick Mathewson2012-09-06
| | | | | | | We were trying to incorporate all headers in common_sha1.i, not just the src/common ones. This is part of bug 6778; fix on 0.2.4.1-alpha
* build: minimal adjustments to make out-of-tree build workJim Meyering2012-08-27
|
* Make the _sha1.i file generation quieterNick Mathewson2012-08-23
|
* Fix up make distcheck and greatly simplify docs dependencies (although it's ↵Stewart Smith2012-08-09
| | | | still a bit odd)
* fix dependencies for some generated filesStewart Smith2012-08-09
|
* Move to non-recursive makeStewart Smith2012-08-09
This gives us a few benefits: 1) make -j clean all this will start working, as it should. It currently doesn't. 2) increased parallel build recursive make will max out at number of files in a directory, non-recursive make doesn't have such a limitation 3) Removal of duplicate information in make files, less error prone I've also slightly updated how we call AM_INIT_AUTOMAKE, as the way that was used was not only deprecated but will be *removed* in the next major automake release (1.13).... so probably best that we can continue to bulid tor without requiring old automake. (see http://www.gnu.org/software/automake/manual/html_node/Public-Macros.html ) For more reasons why, see resources such as: http://miller.emu.id.au/pmiller/books/rmch/
generated by cgit v1.2.3 (git 2.45.0) at 2024-11-30 02:51:16 +0000