This is a tweak for the tor-fw-helper port to windows.

- Update configure script to test for libminiupnpc along with the
  libws2_32 and libiphlpapi libraries required by libminiupnpc
- When building tor-fw-helper, link in libiphlpapi
- Link in libminiupnpc statically becasue I could not get the DLL
  to link properly
- Call WSAStartup before doing network operations
- Fix up a compiler warning about uninitialized backend_state

N.B. The changes to configure.in and Makefile.am will break on non-
Windows platforms.

(Earlier Libevent versions have bufferevent bugs that affect us, and
are missing some APIs that it would be handy to use.)

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.

Jacob Appelbaum authored 13 years ago and Roger Dingledine committed 13 years ago

libnatpmp-20110618 changed the API that tor-fw-helper used and for a time
tor-fw-helper could not build against the newest libnatpmp. This patch brings
support for libnatpmp to tor-fw-helper.

The tor_memcmp code is by Robert Ransom, and the tor_memeq code is
by me.  Both incorporate some ideas from DJB's stuff.

When configure tor with --enable-bufferevents and
--enable-static-libevent, libevent_openssl would still be linked
dynamically. Fix this and refactor src/or/Makefile.am along the way.

Improve the INSTALL documentation for static builds, remove a few
unnecessary lines from configure.in and tweak the changelog message
slightly.

Jacob Appelbaum authored 14 years ago and Sebastian Hahn committed 13 years ago

This implements the feature request in bug #2702

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.

Steven Murdoch authored 14 years ago and Sebastian Hahn committed 14 years ago

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

John Brooks authored 14 years ago and Nick Mathewson committed 14 years ago

Fix for #2358

C99 allows a syntax for structures whose last element is of
unspecified length:
   struct s {
     int elt1;
     ...
     char last_element[];
   };

Recent (last-5-years) autoconf versions provide an
AC_C_FLEXIBLE_ARRAY_MEMBER test that defines FLEXIBLE_ARRAY_MEMBER
to either no tokens (if you have c99 flexible array support) or to 1
(if you don't).  At that point you just use offsetof
[STRUCT_OFFSET() for us] to see where last_element begins, and
allocate your structures like:

   struct s {
     int elt1;
     ...
     char last_element[FLEXIBLE_ARRAY_MEMBER];
   };

   tor_malloc(STRUCT_OFFSET(struct s, last_element) +
                                   n_elements*sizeof(char));

The advantages are:

   1) It's easier to see which structures and elements are of
      unspecified length.
   2) The compiler and related checking tools can also see which
      structures and elements are of unspecified length, in case they
      wants to try weird bounds-checking tricks or something.
   3) The compiler can warn us if we do something dumb, like try
      to stack-allocate a flexible-length structure.

Still to go: some pipes, all stdio files.

Having very long single lines with lots and lots of things in them
tends to make files hard to diff and hard to merge.  Since our tools
are one-line-at-a-time, we should try to construct lists that way too,
within reason.

This incidentally turned up a few headers in configure.in that we were
for some reason searching for twice.

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.

-Wpointer-sign is implied with -Wall, which we use when building with
--enable-gcc-warnings.

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.

Currently the unit tests test_util_spawn_background_* assume that they
are run from the Tor build directory. This is not the case when running
make distcheck, so the test will fail. This problem is fixed by autoconf
setting BUILDDIR to be the root of the Tor build directory, and this
preprocessor variable being used to specify the absolute path to
test-child. Also, in test-child, do not print out argv[0] because this will
no longer be predictable. Found by Sebastian Hahn.

3d6e2830 silenced the autogen.sh warnings as it was supposed to, but
introduced two bugs. Fix them.

Follow-up fix to 3d6e2830 for configure.in additions in master that
weren't in maint-0.2.2

It looks like autoconf 2.68 introduced a bunch of new warnings when it
didn't like the syntax you used or forgot to use
AC_LANG_(SOURCE|PROGRAM).