Port tor-fw-helper to Windows

tor-fw-helper needs to work on Windows too.

changed milestone to %Tor: 0.2.3.x-final

added component::core tor/tor milestone::Tor: 0.2.3.x-final owner::sjmurdoch parent::1775 priority::high resolution::fixed status::closed tor-relay type::enhancement version::tor unspecified windows labels

Trac:
Parent: #1900 (moved) to #1775 (moved)

Trac:
Points: N/A to N/A
Actualpoints: N/A to N/A
Priority: normal to major
Milestone: Deliverable-Mar2011 to Tor: 0.2.3.x-final

The patch to build tor-fw-helper on Windows is ready for review (but not merge: it breaks on non-Windows platforms). I would like to know how best to make it cross-platform.

The patch is 2ad336f999781db211d92332e657398829c8799c in git://git.torproject.org/sjm217/tor.git (branch bug1983-port-tor-fw-helper-to-windows)

Build using:

./autogen.sh
./configure --enable-upnp --enable-gcc-warnings --disable-asciidoc --with-libminiupnpc-dir=/local/lib

Oddly, while I specified miniupnpc to be searched for in /local/lib, the Makefile looks for it in /usr/local/lib. The two directories are actually the same one, but I'm not sure why this is happening.

gcc  -g -O2 -Wall -fno-strict-aliasing -W -Wfloat-equal -Wundef -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls
-Wchar-subscripts -Wcomment -Wformat=2 -Wwrite-strings -Wmissing-declarations
-Wredundant-decls -Wnested-externs -Wbad-function-cast -Wswitch-enum -Werror
-Winit-self -Wmissing-field-initializers -Wdeclaration-after-statement
-Wold-style-definition -Waddress -Wmissing-noreturn -Wstrict-overflow=1
-Wnormalized=id -Woverride-init -Wextra -Warray-bounds  -L/usr/local/lib
-Wl,--nxcompat -Wl,--dynamicbase -o tor-fw-helper.exe tor_fw_helper-tor-fw-helper.o
tor_fw_helper-tor-fw-helper-natpmp.o tor_fw_helper-tor-fw-helper-upnp.o
../../common/libor.a  -lminiupnpc -lm-liphlpapi -lws2_32

Another question is that I get the following warning. Is this OK?

Warning: resolving _getaddrinfo by linking to _getaddrinfo@16
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups

Trac:
Status: new to needs_review

So the easiest fix for the the configure.in issue is to look at the trick we already do for libevent, where TOR_LIB_WS32 is defined conditionally if we're building for win32. I've pushed a patch to branch bug1983-port-tor-fw-helper-to-windows on my own public repository; it's not tested, but it'll probably work (or work with a little tweaking). Other than that, the patch looks fine to me.

The search path issue is downright ugly ; nearly all of our TOR_SEARCH_LIB macros need revision or replacement. It's orthogonal to this work, though, so I think we're in the clear.

The getaddrinfo issue looks like we're somehow building or linking or declaring in a way that mingw wasn't expecting, but knows how to work around. It's not pretty; we should fix it; but it's not IMO a showstopper for now. See http://www.delorie.com/gnu/docs/binutils/ld_4.html for a little info on --enable-stdcall-fixup and what it's doing.

Ah, that's how to do it; thanks. I've merged your changes to my branch bug1983-port-tor-fw-helper-to-windows (modulo a little tweak). It builds both on Windows and MacOS X so I expect it will be fine now.

This blog post http://programmingrants.blogspot.com/2009/09/tips-on-undefined-reference-to.html suggests that the getaddrinfo warning is due to miniupnpc not setting WINVER despite assuming Windows XP or later. When I get to writing up the build instructions for libminiupnpc, I'll investigate this further (I already had to set WINVER in some files to make it compile at all).

I'll remove the needs_review flag, and merge this branch into bug2046 (changes to Tor for launching tor-fw-helper on Windows). Once bug2046 is in a better state I'll prod you to review it too.

Trac:
Owner: N/A to sjmurdoch
Status: needs_review to accepted

This code was merged in along with #2046 (moved).

Trac:
Status: accepted to closed
Resolution: N/A to fixed

I've added some changes to build the NAT-PMP components of tor-fw-helper on Windows. The can be found in my bug1983-port-tor-fw-helper-to-windows branch (a65212e371334c95292da1ca460d9d1d9a84d38e in git://git.torproject.org/sjm217/tor.git).

See https://gitweb.torproject.org/sjm217/tor.git/shortlog/refs/heads/bug1983-port-tor-fw-helper-to-windows

Building requires a very slightly modified libnatpmp; see https://gitweb.torproject.org/user/sjm217/libnatpmp-patches.git

Trac:
Resolution: fixed to N/A
Status: closed to reopened

Trac:
Status: reopened to needs_review

Merging those too. But you've got more problems in wait_until_fd_readable(): the right type for a socket on windows is SOCKET, which is "unsigned int" on 32-bit platforms, but "UINT_PTR" on 64-bit windows.

This might be more pervasive than just that function, if the code is using "int" to hold sockets elsewhere.

(Also, select() only works on sockets on windows, but I think you're giving it a socket, so that's ok)

Trac:
Status: needs_review to assigned

Trac:
Keywords: N/A deleted, windows added

Made the tor_socket_t fix in ee717f35c44fa0ec3fc37ca8865a80e321105c33; closing

Trac:
Status: assigned to closed
Resolution: N/A to fixed

Trac:
Keywords: windows deleted, windows tor-relay added

Trac:
Component: Tor Relay to Tor

closed

mentioned in issue #2030 (moved)

moved to tpo/core/tor#1983 (closed)