[tor-bugs] #22839 [Core Tor/Tor]: Build tor with Rust code enabled on Windows

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun Aug 13 17:08:57 UTC 2017


#22839: Build tor with Rust code enabled on Windows
--------------------------------------+----------------------------------
 Reporter:  isis                      |          Owner:  snoek
     Type:  task                      |         Status:  assigned
 Priority:  Medium                    |      Milestone:  Tor: unspecified
Component:  Core Tor/Tor              |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  rust, windows, tor-build  |  Actual Points:
Parent ID:                            |         Points:  1
 Reviewer:                            |        Sponsor:  SponsorZ
--------------------------------------+----------------------------------

Comment (by snoek):

 That was an interesting journey :)

 tl;dr: Except for a gcc invocation reordering issue and a workaround for a
 possible Rust bug, things just work, as long as you have the right
 environment set up: MSYS2, to which we should probably migrate. I made two
 seperate commits for the rust changes and for what looks like a test bug.
 See below. I also opened a bug report on Rust for another issue, which I
 haven't yet heard a comment on.

 The long story:

 Very little work needed to be done on the Tor code proper to make Windows
 integration work:
 - I found one issue where the tor_util Rust object file on Windows depends
 on windows libraries, which were declared before the object file when
 invoking gcc.
 - The static library made by rustc using the MinGW toolchain had a MSVC
 suffix and prefix. So it was called tor_util.lib instead of libtor_util.a.
 I think this is a but in the rust compiler as .lib files and .a files
 don't have the same format. A few days ago I filed a bug for this against
 Rust (https://github.com/rust-lang/rust/issues/43749). To work around this
 I added an extra variable in configure.ac that should resolve this for
 now.

 Here's the commit for these changes: https://github.com/rust-
 lang/rust/issues/43749

 @alexcrichton, if you happen to read this, it just so happens that you
 fixed Rust bug 29508, which is the inverse of this possible Rust bug I
 described above in that MSVC static libs had the GCC .a naming. Any
 thoughts?

 And also Rust itself needs to be setup correctly. This is basically a
 matter of using rustup, and configuring the target triple. This is all
 fairly standard Rust fare, but I think it's useful to have something up on
 the wiki. I can add this.

 Getting Rust integration working did have some dependencies on how the
 environment is set up. Because Rust expects to use the MSYS2 GCC compiler
 (mingw-w64-i686-toolchain), which has better support for native Windows
 things. At the moment this just causes an issue with snprintf not being
 resolved, but in general we should be using the MSYS2 universe if our
 target is MinGW.

 Which brings us to the fact that Tor is built with the olden MinGW/MSYS
 for its Jenkins builds. And I'm guessing these are used for that actual
 release artifacts. Also, of course other people outside of the Tor project
 proper might still be building Tor with some older non-MSYS2 Windows posix
 system. Another downside is that MSYS2 can't be installed on XP anymore.

 So is moving towards MSYS2 acceptable? My guess would be yes. The old
 MinGW doesn't seem to be maintained much anymore, MSYS2 seems a lot nicer
 to work with (has an actual package manger Pacman, ported from Arch), and
 it has better Windows integration. But I'm not too versed in all of this.

 As for testing this: I've compiled this for MSYS2 with and without Rust
 support, and things seemed to go fine mostly. I ran `make check`, and
 three tests didn't pass. Two didn't seem to have anything to do with my
 changes. One was definitely a 'Windows does pathnames backwards' bug (so
 only that one test failed in the main `test` test) and has happened on the
 Tor Jenkins builds as well. One failure happened in test_keygen.sh, ("Tor
 didn't declare that there would be no encryption"). This one happens on
 MSYS2 with and without Rust integration. Perhaps it was my env setup in
 some way. Haven't digged into this one yet, but it makes sense as being a
 separate bug.

 The last test, test_memwipe, segfaulted. This only happened with Rust
 built in. It turns out this was caused by the uninitialized buf in
 check_heap_buffer being smaller than the mem addresses being scanned. I
 know we're doing some dirty stuff there, but I don't think trying to read
 past the length of the buffer was intended. At least to me it seems fair
 enough for the program to segfault. I put in the obvious fix, which might
 be horribly wrong.

 commit for that fix:
 https://github.com/stuij/tor/commit/e6f552a184be8c5cee563e837dc33d9d038af88c

 I don't forsee the Rust patch having any influence on environments that
 are not Windows, and on Windows, only a configuration with rust enabled
 should see any change, as in that it should now work, hopefully :)

 Cross compiling from Linux to Windows should also work now if Rust is set
 up properly, but I haven't tested this. Before putting effort into this it
 seemed better to see what will happen with all of this.

 Since configuring the build environment seems to happen out-of-tree (at
 least the trees that I found), obviously work still needs to be done to
 get a Rust compiler set up and configured for MinGW on Windows on the
 relevant boxes. That should go hand in hand with MSYS2 work.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22839#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list