Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:04:38Zhttps://gitlab.torproject.org/legacy/trac/-/issues/21023Replace custom checks with Autoconf macros2020-06-13T15:04:38ZcypherpunksReplace custom checks with Autoconf macrosRemoving environ in #19142 didn't work on BSDs but the check in `configure.ac` can be simplified. Autoconf provides the `AC_CHECK_DECL` macro for these kinds of checks and turns the current check into a oneliner.
The `malloc(0)` check c...Removing environ in #19142 didn't work on BSDs but the check in `configure.ac` can be simplified. Autoconf provides the `AC_CHECK_DECL` macro for these kinds of checks and turns the current check into a oneliner.
The `malloc(0)` check can also be simplified by replacing it with the `AC_FUNC_MALLOC` macro.
These are only two candidates I've found so far, there are probably more hence this ticket.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20986Gracefully handle build configurations on systems without AsciiDoc2020-06-13T15:04:26ZcypherpunksGracefully handle build configurations on systems without AsciiDocOn systems without AsciiDoc the build configuration aborts telling users to pass `--disable-asciidoc`. This requires users to restart the build configuration which is annoying.
Instead the build configuration should handle these cases g...On systems without AsciiDoc the build configuration aborts telling users to pass `--disable-asciidoc`. This requires users to restart the build configuration which is annoying.
Instead the build configuration should handle these cases gracefully and show a message without aborting the configuration. In these cases i would also show a less verbose message and change it to something similar to systems without Python, see https://gitweb.torproject.org/tor.git/tree/configure.ac?id=4098bfa26073551fe3f525ada7fc9079a49fd4bb#n218.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19518Configure argument --without-tcmalloc causes linking with libtcmalloc library2020-06-13T14:59:03Zyurivict271Configure argument --without-tcmalloc causes linking with libtcmalloc libraryOnly --with-tcmalloc should link with the library.
Please make sure that this and other --with-xxxx flags don't malfunction this way.Only --with-tcmalloc should link with the library.
Please make sure that this and other --with-xxxx flags don't malfunction this way.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19381wish: conditionally build man page (tor.1) and html doc using independent con...2020-06-13T14:58:38Ztoralfwish: conditionally build man page (tor.1) and html doc using independent configure options
Currently it is practice in Gentoo Linux to install at least the the man page.
However that creation is coupled to the html files too (right ?) and therefore forces the Tor package to pull in more - otherwise completely unneeded - depen...
Currently it is practice in Gentoo Linux to install at least the the man page.
However that creation is coupled to the html files too (right ?) and therefore forces the Tor package to pull in more - otherwise completely unneeded - dependent packages.
De-coupling tor.1 from the html docs would at least allow us in the Gentoo Linux universe to get rid of packages like libxslt and friends at a dedicated Tor relay.Tor: 0.4.2.x-finalDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19174libscrypt check fails when libscrypt requires libm2020-06-13T14:57:57ZNick Mathewsonlibscrypt check fails when libscrypt requires libmSee #19161 for background.
When libscrypt requires libm, our current check fails to detect libscrypt. This caused a failure to build (#19161), which we fixed by not calling libscrypt_scrypt() unless that function was actually found.
Bu...See #19161 for background.
When libscrypt requires libm, our current check fails to detect libscrypt. This caused a failure to build (#19161), which we fixed by not calling libscrypt_scrypt() unless that function was actually found.
But we still have a problem here: We would like to detect libscrypt in these cases, and actually use it as appropriate.
Isis and I wrote a solution in isis's branch `bug19161_028`, but it has some remaining infelicities, I think. Will transcribe those in a comment.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/11659Turn python test scripts into proper TESTS elements2020-06-13T14:35:57ZNick MathewsonTurn python test scripts into proper TESTS elementsRight now we use the check-local target to run the python unit tests. But that's kinda janky; we could be doing better if we had them be part of TESTS, which is feasible if we do the right automake incantations.
See https://www.gnu.org...Right now we use the check-local target to run the python unit tests. But that's kinda janky; we could be doing better if we had them be part of TESTS, which is feasible if we do the right automake incantations.
See https://www.gnu.org/software/automake/manual/html_node/Parallel-Test-Harness.html for some tips on how to do this properly.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6936link to librt and libdl only when needed2020-06-13T14:23:03Zweasel (Peter Palfrader)link to librt and libdl only when neededAccording to dpkg-shlibdeps, the three binaries in tor, tor-resolve, tor-gencert, and tor, link to libdl.so.2 and librt.so.1. without using any of their symbols.
```
dpkg-shlibdeps: warning: dependency on libdl.so.2 could be avoided if ...According to dpkg-shlibdeps, the three binaries in tor, tor-resolve, tor-gencert, and tor, link to libdl.so.2 and librt.so.1. without using any of their symbols.
```
dpkg-shlibdeps: warning: dependency on libdl.so.2 could be avoided if "debian/tor/usr/bin/tor-resolve debian/tor/usr/sbin/tor debian/tor/usr/bin/tor-gencert" were not uselessly linked against it (they use none of its symbols).
dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if "debian/tor/usr/bin/tor-resolve debian/tor/usr/sbin/tor debian/tor/usr/bin/tor-gencert" were not uselessly linked against it (they use none of its symbols).
```
Why do we link against them? Should we?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: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6622Tor link against static zlib broken by -pie switch2020-06-13T14:21:54ZTracTor link against static zlib broken by -pie switchBuild environment: CentOS v5.8/x86_64 with GCC v4.4.6.
I'm linking Tor against staticly-built versions of zlib (v1.2.7) and OpenSSL (v1.0.1c). This has always worked correctly with the 0.2.2.x versions of Tor. With version 0.2.3-20-rc...Build environment: CentOS v5.8/x86_64 with GCC v4.4.6.
I'm linking Tor against staticly-built versions of zlib (v1.2.7) and OpenSSL (v1.0.1c). This has always worked correctly with the 0.2.2.x versions of Tor. With version 0.2.3-20-rc the final link fails with this error:
$ gcc44 -m64 -O2 -g -march=native -mno-avx -D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector -fwrapv --param ssp-buffer-size=1 -fPIE -Wall -fno-strict-aliasing -L/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib -pie -z relro -z now -o tor tor_main.o ./libtor.a ../common/libor.a ../common/libor-crypto.a ../common/libor-event.a /home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libz.a -lm /home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libevent.a /home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libssl.a /home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libcrypto.a /home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libz.a -ldl -lrt
/usr/bin/ld: /home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libz.a(deflate.o): relocation R_X86_64_32S against `_length_code' can not be used when making a shared object; recompile with -fPIC
/home/rpmbuild/BUILD/tor-0.2.3.20-rc/dependencies/lib/libz.a: could not read symbols: Bad value
Removing that -pie switch allows the link to complete successfully.
The GCC doc suggests that the linking error is due to not having used -pie during compilation. This seems to be true as neither zlib nor openssl nor libevent are compiled with this switch (or with -fPIC). Not even the Tor source is compiled with -pie. It is used nowhere until that final link.
The offending symbol is defined in zlib's deflate.c, which is compiled with this command line:
gcc44 -m64 -O2 -g -march=native -mno-avx -c -o deflate.o deflate.c
Do we really need this -pie switch when linking Tor? What is the adverse impact if I just remove it from the linker input?
**Trac**:
**Username**: tmpname0901Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/6311Migrate TOR_SEARCH_LIBRARY to use pkg-config2020-06-13T14:20:55ZNick MathewsonMigrate TOR_SEARCH_LIBRARY to use pkg-configTOR_SEARCH_LIBRARY is a hard-to-maintain fragile garden of venomous snakes, all waiting to bite you at the same time.
I'm working on a patch to migrate to pkg-config. pkg-config is everywhere these days, and where it isn't, we can fal...TOR_SEARCH_LIBRARY is a hard-to-maintain fragile garden of venomous snakes, all waiting to bite you at the same time.
I'm working on a patch to migrate to pkg-config. pkg-config is everywhere these days, and where it isn't, we can fall back to the old thing for a while.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/5683add libtool support to tor2020-06-13T14:19:17ZTracadd libtool support to torUsing libtool standardizes building shared or static libraries in a portable manner.
**Trac**:
**Username**: rsavoyeUsing libtool standardizes building shared or static libraries in a portable manner.
**Trac**:
**Username**: rsavoyeTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4692If only a working static OpenSSL is available, ./configure fails2020-06-13T14:15:56ZSteven MurdochIf only a working static OpenSSL is available, ./configure failsIf OpenSSL is available, but only the statically linked version works, ./configure will fail. This is because the autoconf test program will be by default built dynamically, at least on Windows, even if --enable-static-openssl is set. Th...If OpenSSL is available, but only the statically linked version works, ./configure will fail. This is because the autoconf test program will be by default built dynamically, at least on Windows, even if --enable-static-openssl is set. The attached patch (appears to) resolve this problem on Windows.
However, the patch doesn't work on MacOS X because passing -static to the compiler causes it to fail with the error "ld: library not found for -lcrt0.o". I presume MacOS X can't produce fully static binaries for whatever reason.
What I'd really like to do is pass "$TOR_LIBDIR_openssl/libssl.a $TOR_LIBDIR_openssl/libcrypto.a" into the link path of the test program built by TOR_SEARCH_LIBRARY(openssl, ...). However, $TOR_LIBDIR_ is being set by TOR_SEARCH_LIBRARY so there is a chicken and egg problem here which I'm not sure how to resolve.
These tests were done on Tor version e4cebb76c5577b1a39b752cc694147e929662c4a.Tor: unspecified