nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-11 13:43:47 +01:00
Code Issues Packages Projects Releases Wiki Activity
fab99844fc
tor/src/common/include.am

99 lines
2.7 KiB
Plaintext
Raw Normal View History

Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
noinst_LIBRARIES+= src/common/libor.a src/common/libor-crypto.a src/common/libor-event.a
EXTRA_DIST+= \
src/common/common_sha1.i \
src/common/Makefile.nmake
#CFLAGS = -Wall -Wpointer-arith -O2
build: minimal adjustments to make out-of-tree build work
2012-08-27 16:00:22 +02:00
AM_CPPFLAGS += -I$(srcdir)/src/common -Isrc/common
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
if USE_OPENBSD_MALLOC
Move all externally maintained source files into src/ext The rationale for treating these files differently is that we should be checking upstream for changes as applicable, and merging changes upstream as warranted.
2012-10-11 23:19:37 +02:00
libor_extra_source=src/ext/OpenBSD_malloc_Linux.c
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
else
libor_extra_source=
endif
Build donna32 with -fomit-frame-pointer
2013-01-30 19:08:04 +01:00
src_common_libcurve25519_donna_a_CFLAGS=
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
if BUILD_CURVE25519_DONNA
Make libcurve25519_donna get built as a .a This lets us give it compiler flags differing from the rest of libor-crypto.a
2012-12-06 18:07:58 +01:00
src_common_libcurve25519_donna_a_SOURCES=\
src/ext/curve25519_donna/curve25519-donna.c
Build donna32 with -fomit-frame-pointer
2013-01-30 19:08:04 +01:00
src_common_libcurve25519_donna_a_CFLAGS+=\
@F_OMIT_FRAME_POINTER@
Make libcurve25519_donna get built as a .a This lets us give it compiler flags differing from the rest of libor-crypto.a
2012-12-06 18:07:58 +01:00
noinst_LIBRARIES+=src/common/libcurve25519_donna.a
LIBDONNA=src/common/libcurve25519_donna.a
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
else
if BUILD_CURVE25519_DONNA_C64
Make libcurve25519_donna get built as a .a This lets us give it compiler flags differing from the rest of libor-crypto.a
2012-12-06 18:07:58 +01:00
src_common_libcurve25519_donna_a_SOURCES=\
src/ext/curve25519_donna/curve25519-donna-c64.c
noinst_LIBRARIES+=src/common/libcurve25519_donna.a
LIBDONNA=src/common/libcurve25519_donna.a
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
else
Make libcurve25519_donna get built as a .a This lets us give it compiler flags differing from the rest of libor-crypto.a
2012-12-06 18:07:58 +01:00
LIBDONNA=
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
endif
endif
Make libcurve25519_donna get built as a .a This lets us give it compiler flags differing from the rest of libor-crypto.a
2012-12-06 18:07:58 +01:00
if CURVE25519_ENABLED
libcrypto_extra_source=src/common/crypto_curve25519.c
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
endif
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
src_common_libor_a_SOURCES = \
src/common/address.c \
src/common/compat.c \
src/common/container.c \
src/common/di_ops.c \
src/common/log.c \
src/common/memarea.c \
src/common/mempool.c \
src/common/procmon.c \
src/common/util.c \
src/common/util_codedigest.c \
$(libor_extra_source)
src_common_libor_crypto_a_SOURCES = \
src/common/aes.c \
src/common/crypto.c \
Fix compilation with --disable-curve25519 option 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.
2013-02-04 17:32:55 +01:00
src/common/crypto_format.c \
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
src/common/torgzip.c \
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
src/common/tortls.c \
$(libcrypto_extra_source)
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
src_common_libor_event_a_SOURCES = src/common/compat_libevent.c
Fix a build-warning when building out-of-tree 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
2012-09-06 15:56:48 +02:00
COMMONHEADERS = \
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
src/common/address.h \
src/common/aes.h \
src/common/ciphers.inc \
src/common/compat.h \
src/common/compat_libevent.h \
src/common/container.h \
src/common/crypto.h \
Add a wrapper around, and test and build support for, curve25519. 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.
2012-12-03 21:44:21 +01:00
src/common/crypto_curve25519.h \
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
src/common/di_ops.h \
src/common/memarea.h \
src/common/mempool.h \
src/common/procmon.h \
src/common/torgzip.h \
src/common/torint.h \
src/common/torlog.h \
src/common/tortls.h \
src/common/util.h
Fix a build-warning when building out-of-tree 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
2012-09-06 15:56:48 +02:00
noinst_HEADERS+= $(COMMONHEADERS)
Fix up make distcheck and greatly simplify docs dependencies (although it's still a bit odd)
2012-08-03 03:20:52 +02:00
DISTCLEANFILES+= src/common/common_sha1.i
Fix a build-warning when building out-of-tree 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
2012-09-06 15:56:48 +02:00
src/common/common_sha1.i: $(libor_SOURCES) $(libor_crypto_a_SOURCES) $(COMMONHEADERS)
Make the _sha1.i file generation quieter
2012-08-23 19:14:41 +02:00
$(AM_V_GEN)if test "@SHA1SUM@" != none; then \
Fix a build-warning when building out-of-tree 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
2012-09-06 15:56:48 +02:00
(cd "$(srcdir)" && "@SHA1SUM@" $(src_common_libor_SOURCES) $(src_common_libor_crypto_a_SOURCES) $(COMMONHEADERS)) | "@SED@" -n 's/^\(.*\)$$/"\1\\n"/p' > $@; \
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
elif test "@OPENSSL@" != none; then \
Fix a build-warning when building out-of-tree 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
2012-09-06 15:56:48 +02:00
(cd "$(srcdir)" && "@OPENSSL@" sha1 $(src_common_libor_SOURCES) $(src_Common_libor_crypto_a_SOURCES) $(COMMONHEADERS)) | "@SED@" -n 's/SHA1(\(.*\))= \(.*\)/"\2 \1\\n"/p' > $@; \
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
else \
Fix up make distcheck and greatly simplify docs dependencies (although it's still a bit odd)
2012-08-03 03:20:52 +02:00
rm $@; \
touch $@; \
Move to non-recursive make 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/
2012-08-02 15:31:43 +02:00
fi
Fix up make distcheck and greatly simplify docs dependencies (although it's still a bit odd)
2012-08-03 03:20:52 +02:00
src/common/util_codedigest.o: src/common/common_sha1.i
Drop support for openssl 0.9.7 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.
2012-09-13 01:25:58 +02:00
Reference in New Issue Copy Permalink