Opened 9 years ago

Closed 7 years ago

Last modified 7 years ago

#1983 closed enhancement (fixed)

Port tor-fw-helper to Windows

Reported by: ioerror Owned by: sjmurdoch
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Keywords: windows tor-relay
Cc: nickm sjmurdoch Actual Points:
Parent ID: #1775 Points:
Reviewer: Sponsor:

Description

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

Child Tickets

TicketTypeStatusOwnerSummary
#2046taskclosedsjmurdochPort Tor code for starting a background process to Windows

Change History (13)

comment:1 Changed 9 years ago by ioerror

Parent ID: #1900#1775

comment:2 Changed 8 years ago by nickm

Milestone: Deliverable-Mar2011Tor: 0.2.3.x-final
Priority: normalmajor

comment:3 Changed 8 years ago by sjmurdoch

Status: newneeds_review

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

comment:4 Changed 8 years ago by nickm

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.

comment:5 Changed 8 years ago by sjmurdoch

Owner: set to sjmurdoch
Status: needs_reviewaccepted

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.

comment:6 Changed 8 years ago by sjmurdoch

Resolution: fixed
Status: acceptedclosed

This code was merged in along with #2046.

comment:7 Changed 7 years ago by sjmurdoch

Resolution: fixed
Status: closedreopened

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

comment:8 Changed 7 years ago by sjmurdoch

Status: reopenedneeds_review

comment:9 Changed 7 years ago by nickm

Status: needs_reviewassigned

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)

comment:10 Changed 7 years ago by nickm

Keywords: windows added

comment:11 Changed 7 years ago by nickm

Resolution: fixed
Status: assignedclosed

Made the tor_socket_t fix in ee717f35c44fa0ec3fc37ca8865a80e321105c33; closing

comment:12 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:13 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.