--enable-gcc-warnings enables two warnings that clang doesn't support,
so the build fails. We had hoped clang 3.0 would add those, but it
didn't, so let's just always disable those warnings when building with
clang. We can still fix it later once they add support
For some reason, autoconf doesn't by default have an "AC_PROG_AR" for
this -- possibly it's assumed that any "ar" you have will work
everyplace.
Fixes bug 3909; found by sid77.
This fixes a build issue first present in fdbdb4dc15, but the bug
(of not using a correct ar) has been in every Tor version ever: it
just didn't matter until then.
Starting with Lion, Apple decided to deprecate the system openssl. We
can start requiring users to install their own openssl once OS X doesn't
ship with it anymore.
Conflicts throughout. All resolved in favor of taking HEAD and
adding tor_mem* or fast_mem* ops as appropriate.
src/common/Makefile.am
src/or/circuitbuild.c
src/or/directory.c
src/or/dirserv.c
src/or/dirvote.c
src/or/networkstatus.c
src/or/rendclient.c
src/or/rendservice.c
src/or/router.c
src/or/routerlist.c
src/or/routerparse.c
src/or/test.c
Autoconf adds -g -O2 by default, so adding it ourselves is not required.
It also caused a warning with clang for every source file, so remove it
here. Fixes last issue of ticket 2696.
- When compiling using clang (2.9 or lower) do not enable
-Wnormalized=id or -Woverride-init when --enable-gcc-warnings
or --enable-gcc-warnings-advisory is set as these options
are unsupported.
We decided to no longer ship expert packages for OS X because they're a
lot of trouble to keep maintained and confuse users. For those who want
a tor on OS X without Vidalia, macports is a fine option. Alternatively,
building from source is easy, too.
The polipo stuff that is still required for the Vidalia bundle build can
now be found in the torbrowser repository,
git://git.torproject.org/torbrowser.git.
When configuring with --enable-gcc-warnings, we use -Wformat=2 which
automatically enables the available -Wformat switches, so adding them
again in the --enable-gcc-hardening case doesn't make sense..
We used to enable ssp-buffer-size=1 only when building with
--enable-gcc-warnings. That would result in warnings (and no
protection for small arrays) when building with
--enable-gcc-hardening without enabling warnings, too. Fixes bug
2031.
Also remove an XXX: We now allow to build with -fstack-protector
by using --enable-gcc-hardening.
Build on Ubuntu 10.04 64-bit was failing:
util.c: In function ‘parse_http_time’:
util.c:1370: error: not protecting function: no buffer at least 8 bytes long
We don't want to lose -Werror, and we don't care too much about the
added overhead of protecting even small buffers, so let's simply turn on
SSP for all buffers.
Thanks to Jacob Appelbaum for the pointer and SwissTorExit for the
original report.
Signed-off-by: Andy Isaacson <adi@hexapodia.org>
This patch adds support for two new configure options:
'--enable-gcc-hardening'
This sets CFLAGS to include:
"-D_FORTIFY_SOURCE=2 -fstack-protector-all"
"-fwrapv -fPIE -Wstack-protector -Wformat -Wformat-security"
"-Wpointer-sign"
It sets LDFLAGS to include:
"-pie"
'--enable-linker-hardening'
This sets LDFLAGS to include:
" -z relro -z now"
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.
Sebastian Hahn
Roger Dingledine
Nick Mathewson
Erinn Clark
Jacob Appelbaum
Steven Murdoch
John Brooks
Linus Nordberg
Andy Isaacson