nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-14 07:03:44 +01:00
Code Issues Packages Projects Releases Wiki Activity
3ad43ef75f
tor/src/tools/Makefile.am

19 lines
822 B
Makefile
Raw Normal View History

r12596@catbus: nickm | 2007-04-30 18:42:44 -0400 New tool to generate key certificates as in proposal 103. needs cleanup svn:r10075
2007-05-01 00:43:01 +02:00
bin_PROGRAMS = tor-resolve tor-gencert
r15558@tombo: nickm | 2008-05-09 04:35:12 -0400 New (temporary) tool to dump the modulus of a key. May help with a project of weasel's. svn:r14580
2008-05-09 10:35:38 +02:00
noinst_PROGRAMS = tor-checkkey
Add a pure-C tor-resolve implementation svn:r2620
2004-10-28 22:28:13 +02:00
tor_resolve_SOURCES = tor-resolve.c
r12611@catbus: nickm | 2007-04-30 22:49:00 -0400 For reasons which make sense to somebody, I'm sure, mingw gcc wants the libraries to appear at the end of the command line. This is done by specifying them with LDADD in Makefile.am, not LDFLAGS. If anybody can explain to me why mingw thinks "gcc -o foo foo.o -lbar" is fine, whereas "gcc -lbar -o foo foo.o" is Doubleplusbad UnMingwThink, I'd quite appreciate it. Until then, I'll just do what seems to work, and hope we don't blunder across any other great slumbering cthonian deities of arbitrary syntax. svn:r10082
2007-05-01 04:53:32 +02:00
tor_resolve_LDFLAGS = @TOR_LDFLAGS_libevent@
Merge commit 'origin/maint-0.2.1' Resolved conflicts in: configure.in src/or/Makefile.am src/tools/Makefile.am
2010-01-24 21:03:45 +01:00
tor_resolve_LDADD = ../common/libor.a -lm @TOR_LIBEVENT_LIBS@ @TOR_LIB_WS32@
Add a pure-C tor-resolve implementation svn:r2620
2004-10-28 22:28:13 +02:00
r12596@catbus: nickm | 2007-04-30 18:42:44 -0400 New tool to generate key certificates as in proposal 103. needs cleanup svn:r10075
2007-05-01 00:43:01 +02:00
tor_gencert_SOURCES = tor-gencert.c
tor_gencert_LDFLAGS = @TOR_LDFLAGS_zlib@ @TOR_LDFLAGS_openssl@ \
r12611@catbus: nickm | 2007-04-30 22:49:00 -0400 For reasons which make sense to somebody, I'm sure, mingw gcc wants the libraries to appear at the end of the command line. This is done by specifying them with LDADD in Makefile.am, not LDFLAGS. If anybody can explain to me why mingw thinks "gcc -o foo foo.o -lbar" is fine, whereas "gcc -lbar -o foo foo.o" is Doubleplusbad UnMingwThink, I'd quite appreciate it. Until then, I'll just do what seems to work, and hope we don't blunder across any other great slumbering cthonian deities of arbitrary syntax. svn:r10082
2007-05-01 04:53:32 +02:00
@TOR_LDFLAGS_libevent@
tor_gencert_LDADD = ../common/libor.a ../common/libor-crypto.a \
Add --enable-static-zlib option Works like the --enable-static-openssl/libevent options. Requires --with-zlib-dir to be set. Note that other dependencies might still pull in a dynamicly linked zlib, if you don't link them in statically too.
2010-04-14 16:48:05 +02:00
-lm @TOR_ZLIB_LIBS@ @TOR_LIBEVENT_LIBS@ @TOR_OPENSSL_LIBS@ @TOR_LIB_WS32@ @TOR_LIB_GDI@
r12611@catbus: nickm | 2007-04-30 22:49:00 -0400 For reasons which make sense to somebody, I'm sure, mingw gcc wants the libraries to appear at the end of the command line. This is done by specifying them with LDADD in Makefile.am, not LDFLAGS. If anybody can explain to me why mingw thinks "gcc -o foo foo.o -lbar" is fine, whereas "gcc -lbar -o foo foo.o" is Doubleplusbad UnMingwThink, I'd quite appreciate it. Until then, I'll just do what seems to work, and hope we don't blunder across any other great slumbering cthonian deities of arbitrary syntax. svn:r10082
2007-05-01 04:53:32 +02:00
r15558@tombo: nickm | 2008-05-09 04:35:12 -0400 New (temporary) tool to dump the modulus of a key. May help with a project of weasel's. svn:r14580
2008-05-09 10:35:38 +02:00
tor_checkkey_SOURCES = tor-checkkey.c
tor_checkkey_LDFLAGS = @TOR_LDFLAGS_zlib@ @TOR_LDFLAGS_openssl@ \
@TOR_LDFLAGS_libevent@
tor_checkkey_LDADD = ../common/libor.a ../common/libor-crypto.a \
Add --enable-static-zlib option Works like the --enable-static-openssl/libevent options. Requires --with-zlib-dir to be set. Note that other dependencies might still pull in a dynamicly linked zlib, if you don't link them in statically too.
2010-04-14 16:48:05 +02:00
-lm @TOR_ZLIB_LIBS@ @TOR_LIBEVENT_LIBS@ @TOR_OPENSSL_LIBS@ @TOR_LIB_WS32@ @TOR_LIB_GDI@
Reference in New Issue Copy Permalink