This tells the windows headers to give us definitions that didn't
exist before XP -- like the ones that we need for IPv6 support.

See bug #5861.  We didn't run into this issue with mingw, since
mingw doesn't respect _WIN32_WINNT as well as it should for some of
its definitions.

We started adding it in 59e2c778 back in 2004, 8 years and 3
days ago.  It's time to deprogram ourselves from this cargo cult.

I think that the trailing __ got added in false analogy to
HAVE_MACRO__func__, HAVE_MACRO__FUNC__, and HAVE_MACRO__FUNCTION__.
But those macros actually indicate the presence of __func__,
__FUNC__, and __FUNCTION__ respectively.  The __ at the end of
HAVE_EXTERN_ENVIRON_DECLARED would only be appropriate if the
environ were declared__, whatever that means.

(As a side-note, HAVE_MACRO__func__ and so on should probably be
renamed HAVE_MACRO___func__ and so on.  But that can wait.)

This is an identifier renaming only.

We'd had our configure.in test include unistd.h unconditionally,
which would fail on Windows/mingw, even though environ _was_
declared there.  Fix for 5704; bugfix on 0.2.3.13-alpha.

Thanks to Erinn for finding this and rransom for figuring out the
problem.

Anthony G. Basile authored 13 years ago and Nick Mathewson committed 12 years ago

The bump from miniupnpc-1.5 to 1.6 changes the definition of
two functions used by tor-fw-helper-upnp.c, upnpDiscover() and
UPNP_AddPortMapping().  This patch addresses this and adds a
check in configure.in for backwards compatibility.

Thanks to Nickolay Kolchin-Semyonov for some hints.

X-Tor-Bug-URL: https://trac.torproject.org/projects/tor/ticket/5434
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=376621


Signed-off-by: Anthony G. Basile <blueness@gentoo.org>

This would cause a redundant redeclaration warning on some versions of
Linux otherwise.

Sebastian Hahn authored 13 years ago and Nick Mathewson committed 13 years ago

OS X would otherwise crash with a segfault when linked statically to
some libraries.

Previously we'd been using "we have clock_gettime()" as a proxy for
"we need -lrt to link a static libevent".  But that's not really
accurate: we should only add -lrt if searching for clock_gettime
function adds -lrt to our libraries.

There was one MS_WINDOWS that remained because it wasn't on a macro
line; a few remaining uses (and the definition!) in configure.in;
and a now-nonsensical stanza of eventdns_tor.h that previously
defined 'WIN32' if it didn't exist.

This option seems to be supported all the way back to at least 10.4, so
enabling it for OS X in general should be fine. If not, someone will
yell.

With no libs statically linked, that's a 3% win in binary size, with
just libevent linked statically, this gives us an advantage of 5% in
terms of binary size, and with libevent and openssl statically linked,
we gain over 18% or over 500KB.

Implements ticket 2915.

Fixes bug 4829; bug not in any released tor.

This resolves bug1827, and lets us avoid freaking people out.
Later, we can use it to get a complete list of our interfaces.

Martin Hebnes Pedersen authored 13 years ago and Nick Mathewson committed 13 years ago

On some platforms (Haiku/BeOS) libm lives in libcore.

Also added 'network' to the list of libraries to search for connect().

--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

- Link in libws32 and libiphlpapi, needed for libnatpmp (both in
  ./configure and when compiling tor-fw-helper-natpmp.c)
- Define STATICLIB under Windows, to allow tor-fw-helper-natpmp.c to link
- Don't include arpa/inet.h which isn't present in Mingw32 and doesn't
  appear to be needed on either Windows or MacOS X

Yes, the timing functions are suboptimal.  Please improve!