Forward-ports parts of the 0.3.2 travis config on top of the 0.2.9
merge.
Also:
* build rust on clang and gcc, Linux and macOS
* build combinations of non-default options on gcc Linux
* exclude broken builds
* log the rustup version
Part of 24629.
Creating the configure flags once avoids inconsistent flags
between configure and distcheck configure.
Echoing the flags helps developers work out what configure is
doing.
(Backported to 0.2.9 and later as a precaution.)
Fixes 27088 on 0.3.4.1-alpha, adds logging in previous releases.
Build on all compilers:
* default options + hardening
Build on gcc:
* coverage (+ no hardening)
* distcheck
* no hardening
Add some extra logging:
* tail config.log on failure
(config.log is too long for travis to render)
Put the config in a more logical order
* Sort config items in chronological order
* Put related items together
Part of 24629.
I hope that the debian clang maintainers will look at debian bug
903709 soon. But until they do, this should keep our users and our
CI happy on sid with clang.
Closes ticket 26779.
If we're building for Windows, we want to use windows threads no
matter what, and we don't want to link a pthread library even if it
is present. Fixes bug 27081; bugfix on 1790dc6760 in 0.1.0.1-rc.
The seccomp rule for the openat syscall checks for the AT_FDCWD
constant. Because this constant is usually a negative value, a
cast to unsigned int is necessary to make sure it does not get
converted to uint64_t used by seccomp.
More info on:
https://github.com/seccomp/libseccomp/issues/69#issuecomment-273805980
When we fixed 25939 in f7633c1fca, we
introduced a call to rescan_periodic_events() from inside the onion
service logic. But this meant that we could rescan the event list --
thereby running event callbacks! -- from inside the hidden service code.
This could cause us to run some of our event callbacks from an
inconsistent state, if we were in the middle of changing options.
A related bug (#25761) prevented us from rescanning our periodic
events as appropriate, but when we fixed THAT one, this bug reared
its ugly head.
The fix here is that "enabling" an event should cause us to run it
from the event loop, but not immediately from the point where we
enable it.
Fixes bug 27003; bugfix on 0.3.4.1-alpha.
We would usually call it through tor_cleanup(), but in some code
paths, we wouldn't. These paths would break restart-in-process,
since leaving fields uncleared would cause assertion failures on
restart.
Fixes bug 26948; bugfix on 0.3.3.1-alpha
