Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:27:26Zhttps://gitlab.torproject.org/legacy/trac/-/issues/26591doc/ missing in build directory for out-of-tree builds2020-06-13T15:27:26ZTracdoc/ missing in build directory for out-of-tree builds**autoconf** allows building tor outside the source directory using `--srcdir=DIR`.
In that case, _doc/_ is not copied or symlinked from source to build directory, causing pages to be unnesseccarily regenerated using **rst2man**.
Would ...**autoconf** allows building tor outside the source directory using `--srcdir=DIR`.
In that case, _doc/_ is not copied or symlinked from source to build directory, causing pages to be unnesseccarily regenerated using **rst2man**.
Would it be possible to adjust the _configure_ stage to account for this?
Specifically, this would allow complete out-of-tree builds at least on OpenBSD, where where the following quirk is required after _configure_ and before _build_ stage to enable separation without **py-docutils** as additional build dependency:
```
pre-build:
ln -sf ${WRKSRC}/doc/ ${WRKBUILD}/
```
**Trac**:
**Username**: knTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25341Remove now-unnecessary Rust linking workaround2020-06-13T15:22:20ZIsis LovecruftRemove now-unnecessary Rust linking workaroundWe've got the following stanza in our `configure.ac`:
```
dnl This is a workaround for #46797
dnl (a.k.a https://github.com/rust-lang/rust/issues/46797 ). O...We've got the following stanza in our `configure.ac`:
```
dnl This is a workaround for #46797
dnl (a.k.a https://github.com/rust-lang/rust/issues/46797 ). Once the
dnl upstream bug is fixed, we can remove this workaround.
case "$host_os" in
darwin*)
TOR_RUST_EXTRA_LIBS="-lresolv"
;;
esac
```
It looks like https://github.com/rust-lang/rust/issues/46797 has been resolved as of 22 January 2018, so we can probably remove this workaround now! (Someone who is on MacOS should probably test this, I don't have access to any Macs right now.)Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24612Fix pretty printing of configure output for rust checks2020-06-13T15:18:51ZIsis LovecruftFix pretty printing of configure output for rust checksRight now we print:
```
[…]
checking for cargo... cargo
checking rust crate dependencies... checking rust version... checking for library containing socket... none required
[…]
```
I think we're supposed to use `AC_MSG_RESULT` to print...Right now we print:
```
[…]
checking for cargo... cargo
checking rust crate dependencies... checking rust version... checking for library containing socket... none required
[…]
```
I think we're supposed to use `AC_MSG_RESULT` to print "yes" if the rust crate dependency checks go okay. After the "checking rust version" we should probably also print something indicating that the version was acceptible (I'd personally go for printing the version string, since it doesn't hurt to have that in the build logs).Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16974./configure script error, when build git version (Centos 6.7)2020-06-13T14:48:45ZTrac./configure script error, when build git version (Centos 6.7)checking whether we need extra options to link openssl... (none)
./configure: line 9437: syntax error near unexpected token `else'
./configure: line 9437: `else'
[root@testserver tor]# rpm -q openssl
openssl-1.0.1e-42.el6.x86_64
[root@te...checking whether we need extra options to link openssl... (none)
./configure: line 9437: syntax error near unexpected token `else'
./configure: line 9437: `else'
[root@testserver tor]# rpm -q openssl
openssl-1.0.1e-42.el6.x86_64
[root@testserver tor]#
Earlier git versions(more then 2 weeks ago- build without problems)
**Trac**:
**Username**: torgituserTor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15248autoconf: drop workarounds for libevent <1.32020-06-13T14:44:17ZNick Mathewsonautoconf: drop workarounds for libevent <1.3All of our checks for u_int_* in configure.ac are unneeded, since Libevent stopped littering its headers with those in 1.3.
Similarly, there are functions that we're checking for which libevent probably has unconditionally in all the ve...All of our checks for u_int_* in configure.ac are unneeded, since Libevent stopped littering its headers with those in 1.3.
Similarly, there are functions that we're checking for which libevent probably has unconditionally in all the versions we support.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15043Use acx_pthread.m4 to find pthreads library2020-06-13T14:43:41ZNick MathewsonUse acx_pthread.m4 to find pthreads libraryIn #9495, we noticed that (it seems) we aren't taking any efforts to compile with threading right on some platforms. Let's fix that by not trying to figure it out ourselves. The acx_pthread.m4 autoconf module is just fine; let's use th...In #9495, we noticed that (it seems) we aren't taking any efforts to compile with threading right on some platforms. Let's fix that by not trying to figure it out ourselves. The acx_pthread.m4 autoconf module is just fine; let's use that in 0.2.7. (It's probably too late to do this in 0.2.6; this is a fiddly part of our build system)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7977Have autoconf detect signed enum2020-06-13T14:26:33ZNick MathewsonHave autoconf detect signed enumOn MSVC, enums are always signed. With #7305, we made an ENUM_BF macro to avoid problems with signed enums. But that macro needs to know whether by default enum types are signed or not. It would be better to detect this with autoconf ...On MSVC, enums are always signed. With #7305, we made an ENUM_BF macro to avoid problems with signed enums. But that macro needs to know whether by default enum types are signed or not. It would be better to detect this with autoconf than just to check for defined(_MSC)Tor: 0.2.4.x-finalhttps://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/1354Configuring Tor with --with*dir gives wrong directories2020-06-13T14:04:28ZSebastian HahnConfiguring Tor with --with*dir gives wrong directoriesI'm trying to configure Tor like this:
./configure --enable-gcc-warnings --with-openssl-dir=/opt/local
--with-zlib-dir=/usr --with-libevent-dir=/usr/local
What happens is that the zlib.h that gets included is from
/opt/local/include, ...I'm trying to configure Tor like this:
./configure --enable-gcc-warnings --with-openssl-dir=/opt/local
--with-zlib-dir=/usr --with-libevent-dir=/usr/local
What happens is that the zlib.h that gets included is from
/opt/local/include, instead of the one in /usr/include.
During configure, I get this as output, though:
checking for zlib directory... /usr/include
checking whether we need extra options to link zlib... (none)
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecified