Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:33:31Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28247Use build.rs in place of test_linking_hack2020-06-13T15:33:31ZNick MathewsonUse build.rs in place of test_linking_hackSee Alex Crichton's comments at https://github.com/torproject/tor/commit/a8ac21fbb5f22b68ffa019b575085c142293bc40#commitcomment-30729271See Alex Crichton's comments at https://github.com/torproject/tor/commit/a8ac21fbb5f22b68ffa019b575085c142293bc40#commitcomment-30729271Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28246Use rust stable in Travis2020-06-13T15:33:30ZNick MathewsonUse rust stable in TravisCurrently we require rust 1.31 (beta?) for use with asan, because of the fixes in #27273.
1. On Travis, we should add a test that uses rust stable without sanitizers.
2. Once Rust 1.31 is stable (December?) we should enable sanitizer...Currently we require rust 1.31 (beta?) for use with asan, because of the fixes in #27273.
1. On Travis, we should add a test that uses rust stable without sanitizers.
2. Once Rust 1.31 is stable (December?) we should enable sanitizers with rust stable.
See Teor's https://trac.torproject.org/projects/tor/ticket/27273#comment:14 for a much more comprehensive version of the matrix.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28244Followup tasks for Rust asan CI fixes2020-06-13T15:33:29ZNick MathewsonFollowup tasks for Rust asan CI fixesOn reviews for #27273, we noted a bunch of tasks to do post-merge. This is a parent ticket to track them.On reviews for #27273, we noted a bunch of tasks to do post-merge. This is a parent ticket to track them.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28209Add single-onion-v2-ipv6-md to chutney, and use it in Tor's make test-network...2020-06-13T15:33:23ZteorAdd single-onion-v2-ipv6-md to chutney, and use it in Tor's make test-network-allsingle-onion-v2-ipv6-md will be a copy of the existing single-onion-ipv6-md, but the onion service version will be more obvious from the name.
Also add single-onion-v2-ipv6 for completeness.single-onion-v2-ipv6-md will be a copy of the existing single-onion-ipv6-md, but the onion service version will be more obvious from the name.
Also add single-onion-v2-ipv6 for completeness.Tor: unspecifiedteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28081rust protover discards all votes if one is not UTF-82020-06-13T15:32:56ZTracrust protover discards all votes if one is not UTF-8
**Trac**:
**Username**: cyberpunks
**Trac**:
**Username**: cyberpunksTor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27805Update CodingStandardsRust.md with allocate_and_copy_string()2020-06-13T15:31:53ZteorUpdate CodingStandardsRust.md with allocate_and_copy_string()We have allocate_and_copy_string() in Rust, which uses tor_malloc():
https://github.com/torproject/tor/blob/master/src/rust/tor_allocate/tor_allocate.rs#L30
We need to update our rust coding standards to mention allocate_and_copy_strin...We have allocate_and_copy_string() in Rust, which uses tor_malloc():
https://github.com/torproject/tor/blob/master/src/rust/tor_allocate/tor_allocate.rs#L30
We need to update our rust coding standards to mention allocate_and_copy_string():
https://gitweb.torproject.org/tor.git/tree/doc/HACKING/CodingStandardsRust.md#n374Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27722rust protover doesn't canonicalize adjacent and overlapping ranges2020-06-13T15:31:26ZTracrust protover doesn't canonicalize adjacent and overlapping ranges`protover.c` accepts both `"Foo=1-3,4-5"` and `"Foo=1-3,2-5"` and then canonicalizes them into `"Foo=1-5"` with `contract_protocol_list()`. Rust rejects the 2nd one as malformed.
**Trac**:
**Username**: cyberpunks`protover.c` accepts both `"Foo=1-3,4-5"` and `"Foo=1-3,2-5"` and then canonicalizes them into `"Foo=1-5"` with `contract_protocol_list()`. Rust rejects the 2nd one as malformed.
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27645Add unit tests for UTF-8 and invalid ContactInfo lines2020-06-13T15:31:08ZteorAdd unit tests for UTF-8 and invalid ContactInfo linesIn #27428, we reject non-UTF-8 ContactInfo lines.
We should add some tests to test_options.c for UTF-8 and invalid ContactInfo lines.In #27428, we reject non-UTF-8 ContactInfo lines.
We should add some tests to test_options.c for UTF-8 and invalid ContactInfo lines.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27468CI: add builds with the latest clang and gcc2020-06-13T15:30:48ZteorCI: add builds with the latest clang and gccWe could add the latest gcc and clang to our Travis matrix.
Travis is running older gcc and clang versions:
* Linux: Ubuntu's older clang and gcc
* macOS: Apple's custom clang, no gcc
Appveyor is already running gcc 8.2, and it seems t...We could add the latest gcc and clang to our Travis matrix.
Travis is running older gcc and clang versions:
* Linux: Ubuntu's older clang and gcc
* macOS: Apple's custom clang, no gcc
Appveyor is already running gcc 8.2, and it seems to be updated every 6-12 months.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27207Examples in CodingStandardsRust.md are wrong2020-06-13T15:29:42ZTracExamples in CodingStandardsRust.md are wrongThe section on `CString` is incorrect:
- `CString::new("bl\x00ah").unwrap().into_raw()` will panic in the 'unwrap' call, it will never return a pointer of any kind, dangling or otherwise.
Also, [12cf04646c571646b726e697d66ecafad7886cf2...The section on `CString` is incorrect:
- `CString::new("bl\x00ah").unwrap().into_raw()` will panic in the 'unwrap' call, it will never return a pointer of any kind, dangling or otherwise.
Also, [12cf04646c571646b726e697d66ecafad7886cf2](https://gitweb.torproject.org/tor.git/commit/doc/HACKING/CodingStandardsRust.md?id=12cf04646c571646b726e697d66ecafad7886cf2) seems to be the result of some miscommunication with [withoutboats](https://github.com/withoutboats):
- `.expect()` is [literally](https://doc.rust-lang.org/std/result/enum.Result.html#method.expect) '`.unwrap()`, but with a custom panic message,' it doesn't return an `Option` and is no safer than unwrap, but it is self-documenting.
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27194Reject protover extra commas in protover2020-06-13T15:29:36ZTracReject protover extra commas in protoverLike how it handles spaces, `protover.c` rejects leading commas (`Link=,1-5` or `Link=,`) while it accepts and ignores extra commas elsewhere (`Link=1-5,` and `Link=1,,,2-5` are valid).
The Rust version accepts and ignores all extra com...Like how it handles spaces, `protover.c` rejects leading commas (`Link=,1-5` or `Link=,`) while it accepts and ignores extra commas elsewhere (`Link=1-5,` and `Link=1,,,2-5` are valid).
The Rust version accepts and ignores all extra commas, including leading commas.
**Trac**:
**Username**: cyberpunksTor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27191handling double spaces in protover2020-06-13T15:29:34ZTrachandling double spaces in protover`protover.c` accepts trailing spaces and extra spaces between subprotocol entries like `"Link=1-4 LinkAuth=1 "`, but rejects leading spaces like `" Link=1-4"`. It has since its [introduction.](https://gitweb.torproject.org/tor.git/commi...`protover.c` accepts trailing spaces and extra spaces between subprotocol entries like `"Link=1-4 LinkAuth=1 "`, but rejects leading spaces like `" Link=1-4"`. It has since its [introduction.](https://gitweb.torproject.org/tor.git/commit/?id=b2b2e1c7f24d9b65059e3d089768d6c49ba4f58f)
The Rust implementation rejects all extra spaces in any position. It's at least consistent.
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27190disparate duplicate subproto handling in protover2020-06-13T15:29:33ZTracdisparate duplicate subproto handling in protover`protover.c` treats `Link=1 Link=1` and `Link=1` identically, allowing duplicate entries without complaint, though it does explicitly check for duplicates to avoid double-counting it as two votes for the same version.
`protover.c` also ...`protover.c` treats `Link=1 Link=1` and `Link=1` identically, allowing duplicate entries without complaint, though it does explicitly check for duplicates to avoid double-counting it as two votes for the same version.
`protover.c` also treats `Link=1 Link=2` and `Link=1-2` the same, while the rust implementation of protover treats `Link=1 Link=2` as if it were `Link=2`.
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27189cleanup rust code2020-06-13T15:29:32ZTraccleanup rust codeThere are low-hanging fruit for silencing clippy lints, removing unnecessary allocations, and writing a more efficient version of `.retain()`.
**Trac**:
**Username**: cyberpunksThere are low-hanging fruit for silencing clippy lints, removing unnecessary allocations, and writing a more efficient version of `.retain()`.
**Trac**:
**Username**: cyberpunksTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/27052document rust/crypto2020-06-13T15:29:04Zcypherpunksdocument rust/cryptoAnd add `#![deny(missing_docs)]` to the top of the files to enforce it.
Attempted in [af182d4ab51d6a1a70559bbdcd4ab842aa855684](https://gitweb.torproject.org/tor.git/commit/?id=af182d4ab51d6a1a70559bbdcd4ab842aa855684) and [b6059297d7cb...And add `#![deny(missing_docs)]` to the top of the files to enforce it.
Attempted in [af182d4ab51d6a1a70559bbdcd4ab842aa855684](https://gitweb.torproject.org/tor.git/commit/?id=af182d4ab51d6a1a70559bbdcd4ab842aa855684) and [b6059297d7cb76f0e00e2098e38d6677d3033340](https://gitweb.torproject.org/tor.git/commit/?id=b6059297d7cb76f0e00e2098e38d6677d3033340) but forgot the exclamation point.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26464Static cross-compiling for Windows is broken2020-06-13T15:27:01ZAlex XuStatic cross-compiling for Windows is brokentwo issues:
1. TOR_OPENSSL_LIBS doesn't include $TOR_LIB_GDI $TOR_LIB_WS32.
2. openssl checking doesn't include -lz.
IMO, both should be fixed by using pkg-config. however, I don't feel like that much pain, so I just made this hacky p...two issues:
1. TOR_OPENSSL_LIBS doesn't include $TOR_LIB_GDI $TOR_LIB_WS32.
2. openssl checking doesn't include -lz.
IMO, both should be fixed by using pkg-config. however, I don't feel like that much pain, so I just made this hacky patch:
```
diff --git a/configure.ac b/configure.ac
index 30f8e63ec..15f4058da 100644
--- a/configure.ac
+++ b/configure.ac
@@ -672,15 +672,18 @@ if test "$bwin32" = "true"; then
# think it's actually necessary.
TOR_LIB_GDI=-lgdi32
TOR_LIB_USERENV=-luserenv
+ TOR_LIB_ZLIB=-lz
else
TOR_LIB_WS32=
TOR_LIB_GDI=
TOR_LIB_USERENV=
+ TOR_LIB_ZLIB=
fi
AC_SUBST(TOR_LIB_WS32)
AC_SUBST(TOR_LIB_GDI)
AC_SUBST(TOR_LIB_IPHLPAPI)
AC_SUBST(TOR_LIB_USERENV)
+AC_SUBST(TOR_LIB_ZLIB)
tor_libevent_pkg_redhat="libevent"
tor_libevent_pkg_debian="libevent-dev"
@@ -812,7 +815,7 @@ AC_ARG_WITH(ssl-dir,
])
AC_MSG_NOTICE([Now, we'll look for OpenSSL >= 1.0.1])
-TOR_SEARCH_LIBRARY(openssl, $tryssldir, [-lssl -lcrypto $TOR_LIB_GDI $TOR_LIB_WS32],
+TOR_SEARCH_LIBRARY(openssl, $tryssldir, [-lssl -lcrypto $TOR_LIB_GDI $TOR_LIB_WS32 $TOR_LIB_ZLIB],
[#include <openssl/ssl.h>
char *getenv(const char *);],
[struct ssl_cipher_st;
@@ -833,10 +836,10 @@ if test "$enable_static_openssl" = "yes"; then
if test "$tor_cv_library_openssl_dir" = "(system)"; then
AC_MSG_ERROR("You must specify an explicit --with-openssl-dir=x option when using --enable-static-openssl")
else
- TOR_OPENSSL_LIBS="$TOR_LIBDIR_openssl/libssl.a $TOR_LIBDIR_openssl/libcrypto.a"
+ TOR_OPENSSL_LIBS="$TOR_LIBDIR_openssl/libssl.a $TOR_LIBDIR_openssl/libcrypto.a $TOR_LIB_GDI $TOR_LIB_WS32 $TOR_LIB_ZLIB"
fi
else
- TOR_OPENSSL_LIBS="-lssl -lcrypto"
+ TOR_OPENSSL_LIBS="-lssl -lcrypto $TOR_LIB_GDI $TOR_LIB_WS32 $TOR_LIB_ZLIB"
fi
AC_SUBST(TOR_OPENSSL_LIBS)
```Tor: unspecifiedAlex XuAlex Xuhttps://gitlab.torproject.org/legacy/trac/-/issues/25605Add tests for Rust protover::compute_for_old_tor() and C functions it calls2020-06-13T15:23:32ZIsis LovecruftAdd tests for Rust protover::compute_for_old_tor() and C functions it callsIn https://trac.torproject.org/projects/tor/ticket/25386#comment:21, after changing/adding some tests, I noticed that `protover::compute_for_old_tor()` always returns an empty string, meaning that the version we parsed is new enough that...In https://trac.torproject.org/projects/tor/ticket/25386#comment:21, after changing/adding some tests, I noticed that `protover::compute_for_old_tor()` always returns an empty string, meaning that the version we parsed is new enough that the router should be reporting its own protocol versions. It's because the Rust code is calling the C version of `tor_version_as_new_as()`, which expects a _platform string_, not a version, so it gets to `tor_version_parse_platform()`, decides this is a "non-standard tor" and returns true early. So, in the top of the Rust function `protover::compute_for_old_tor()`, when we call `tor_version_as_new_as(version, FIRST_TOR_VERSION_TO_ADVERTISE_PROTOCOLS)` it says true, and we never reach the rest of the function.
The solution is to prepend `"Tor "` to each of the query strings in `protover::compute_for_old_tor()`.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24841Your relay has a very large number of connections to other relays. Is your ou...2020-06-13T15:53:07ZTracYour relay has a very large number of connections to other relays. Is your outbound address the same as your relay address?debian-tor-0.3.2.8-rc-1
SOCKSPort 9050
ORPort 80.67.176.53:9001
ORPort [2001:910:1035::1]:9001
ExitRelay 0
https://atlas.torproject.org/#details/A2547D13A3659ECF23AF8B9456B2E277110BF136
```
janv. 08 20:41:35 alex Tor[21674]: Tor 0.3.2...debian-tor-0.3.2.8-rc-1
SOCKSPort 9050
ORPort 80.67.176.53:9001
ORPort [2001:910:1035::1]:9001
ExitRelay 0
https://atlas.torproject.org/#details/A2547D13A3659ECF23AF8B9456B2E277110BF136
```
janv. 08 20:41:35 alex Tor[21674]: Tor 0.3.2.8-rc (git-3696eb720795a666) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.0g, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.3.3.
janv. 08 20:41:35 alex Tor[21674]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
janv. 08 20:41:35 alex Tor[21674]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
janv. 08 20:41:35 alex Tor[21674]: Read configuration file "/etc/tor/torrc".
janv. 08 20:41:35 alex Tor[21674]: Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
janv. 08 20:41:35 alex Tor[21674]: Scheduler type KIST has been enabled.
janv. 08 20:41:35 alex Tor[21674]: Opening Socks listener on 127.0.0.1:9050
janv. 08 20:41:35 alex Tor[21674]: Opening OR listener on 80.67.176.53:9001
janv. 08 20:41:35 alex Tor[21674]: Opening OR listener on [2001:910:1035::1]:9001
janv. 08 20:41:35 alex Tor[21674]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
janv. 08 20:41:35 alex Tor[21674]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
janv. 08 20:41:35 alex Tor[21674]: Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
janv. 08 20:41:35 alex Tor[21674]: Your Tor server's identity key fingerprint is 'tyng A2547D13A3659ECF23AF8B9456B2E277110BF136'
janv. 08 20:41:35 alex Tor[21674]: Bootstrapped 0%: Starting
janv. 08 20:41:38 alex Tor[21674]: Starting with guard context "default"
janv. 08 20:41:38 alex Tor[21674]: Bootstrapped 80%: Connecting to the Tor network
janv. 08 20:41:38 alex Tor[21674]: Signaled readiness to systemd
janv. 08 20:41:38 alex Tor[21674]: Opening Control listener on /var/run/tor/control
janv. 08 20:41:39 alex Tor[21674]: Bootstrapped 85%: Finishing handshake with first hop
janv. 08 20:41:39 alex Tor[21674]: Bootstrapped 90%: Establishing a Tor circuit
janv. 08 20:41:42 alex Tor[21674]: Tor has successfully opened a circuit. Looks like client functionality is working.
janv. 08 20:41:42 alex Tor[21674]: Bootstrapped 100%: Done
janv. 08 20:41:42 alex Tor[21674]: Now checking whether ORPort 80.67.176.53:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
janv. 08 20:41:43 alex Tor[21674]: Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
janv. 08 20:42:41 alex Tor[21674]: Performing bandwidth self-test...done.
janv. 08 23:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 11 connections to 7 relays. Found 11 current canonical connections, in 0 of which we were a non-canonical peer. 4 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 02:41:38 alex Tor[21674]: Heartbeat: Tor's uptime is 5:59 hours, with 2 circuits open. I've sent 4.61 MB and received 16.47 MB.
janv. 09 02:41:38 alex Tor[21674]: Circuit handshake stats since last time: 0/0 TAP, 5/5 NTor.
janv. 09 02:41:38 alex Tor[21674]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 2 v4 connections; and received 0 v1 connections, 0 v2 connections, 1 v3 connections, and 37 v4 connections.
janv. 09 02:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 14 connections to 9 relays. Found 14 current canonical connections, in 0 of which we were a non-canonical peer. 5 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 04:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 15 connections to 10 relays. Found 15 current canonical connections, in 0 of which we were a non-canonical peer. 5 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 05:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 11 connections to 7 relays. Found 11 current canonical connections, in 0 of which we were a non-canonical peer. 4 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 06:41:38 alex Tor[21674]: Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 9 connections to 6 relays. Found 9 current canonical connections, in 0 of which we were a non-canonical peer. 3 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
janv. 09 08:41:38 alex Tor[21674]: Heartbeat: Tor's uptime is 11:59 hours, with 0 circuits open. I've sent 8.13 MB and received 24.95 MB.
janv. 09 08:41:38 alex Tor[21674]: Average packaged cell fullness: 93.781%. TLS write overhead: 16%
janv. 09 08:41:38 alex Tor[21674]: Circuit handshake stats since last time: 0/0 TAP, 1/1 NTor.
janv. 09 08:41:38 alex Tor[21674]: Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 4 v4 connections; and received 0 v1 connections, 0 v2 connections, 4 v3 connections, and 74 v4 connections.
```
**Trac**:
**Username**: tyngTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/23573Do we want to close all connections when tor closes?2020-06-13T15:14:08ZteorDo we want to close all connections when tor closes?I have a branch for privcount that closes all connections before tor shuts down. Is this a feature that we want?I have a branch for privcount that closes all connections before tor shuts down. Is this a feature that we want?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6623--enable-static-tor cannot succeed2020-06-13T15:31:52ZTrac--enable-static-tor cannot succeedBuild environment: CentOS v5.8/x86_64 with GCC v4.4.6.
Use of the --enable-static-tor cannot result in a successful build, at least not with GLibC v2.5.
Use of this flag causes the --static switch to be placed on the compiler command l...Build environment: CentOS v5.8/x86_64 with GCC v4.4.6.
Use of the --enable-static-tor cannot result in a successful build, at least not with GLibC v2.5.
Use of this flag causes the --static switch to be placed on the compiler command line when running tests from the configure script. So when the script tries to verify, say, a working libevent library, the test fails. Then the script falsely believes that the intended test (e.g. finding a linkable libevent lib) has failed. The actual failure is the inability to staticly link GLibC.
Here's as example:
$ gcc44 -o /tmp/conftest -static -I/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/include -I${top_srcdir}/src/common -L/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib -L/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib /tmp/conftest.c -lpthread -ldl -lrt -levent
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a(evutil.o): In function `test_for_getaddrinfo_hacks':
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/libevent-2.0.19-stable/evutil.c:1105: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a(evutil.o): In function `evutil_unparse_protoname':
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/libevent-2.0.19-stable/evutil.c:758: warning: Using 'getprotobynumber' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a(event.o): In function `gettime':
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/libevent-2.0.19-stable/event.c:366: undefined reference to `clock_gettime'
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a(event.o): In function `detect_monotonic':
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/libevent-2.0.19-stable/event.c:336: undefined reference to `clock_gettime'
Ouch! Guess it couldn't find a working libevent.a, right? Wrong!
What linker couldn't do is staticly link GLibC's runtime libraries. Remove that --static from the command line and the configure script's test succeeds in linking against the specified static libevent library.
Tor can be successfully linked against static zlib/openssl/libevent libraries but it cannot be staticly linked against gLibC. This makes --enable-static-tor pointless, a least for Linux builds.
**Trac**:
**Username**: tmpname0901Tor: unspecified