#22831: Merge Snowflake for mac --------------------------------------------+------------------------------ Reporter: dcf | Owner: tbb-team Type: task | Status: | needs_revision Priority: Medium | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: Keywords: snowflake TorBrowserTeam201707 | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: --------------------------------------------+------------------------------
Comment (by dcf): Replying to [comment:3 gk]: > Looks good. The `needs_revision` is mainly for the following nits: > > s/clang 0.3.8/clang 3.8.0/ > > s/The linux descriptor builds its own copy of gn here/The linux descriptor builds its own copy of gn/ > > s/the gn so build/the gn so built/ Made a [https://gitweb.torproject.org/user/dcf/tor-browser- bundle.git/log/?h=snowflake- mac-6&id=faaeb294e36c233021bd2f4afa3d971bb3176c91 snowflake-mac-6] with [https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/diff/?h =snowflake- mac-6&id=faaeb294e36c233021bd2f4afa3d971bb3176c91&id2=f662c9cb1caea6348fe2dcb001d6600f2c813ae0 those changes]. > https://github.com/golang/go/issues/9206#issuecomment-310476743 is used for both path > and timestamp issue. It seems for the latter we want a different URL? That one URL illustrates both the timestamp and the path issues. It only talks about the path issue in the text, though. I couldn't find a more specific link for the timestamp issue. This part of the diff is due to a timestamp: {{{ < 00333430 d4 15 4c 59 00 00 00 00 58 03 00 00 26 03 00 00 |..LY....X...&...| --- > 00333430 dc 15 4c 59 00 00 00 00 58 03 00 00 26 03 00 00 |..LY....X...&...| }}} This part of the diff is due to a path: {{{ < 00359fe0 2f 67 6f 2d 6c 69 6e 6b 2d 34 34 37 31 39 35 39 |/go- link-4471959| < 00359ff0 38 34 2f 67 6f 2e 6f 00 72 75 6e 74 69 6d 65 2e |84/go.o.runtime.| --- > 00359fe0 2f 67 6f 2d 6c 69 6e 6b 2d 32 30 38 38 31 36 34 |/go- link-2088164| > 00359ff0 38 36 2f 67 6f 2e 6f 00 72 75 6e 74 69 6d 65 2e |86/go.o.runtime.| }}} > One thing I was wondering is whether it would be more beneficial to split up the big webrtc patch into > smaller ones. It might make it easier to follow the upstreaming efforts that way giving a clear impression on how many patches still need to get upstreamed and making patches easier to write once one or another of those patches is not needed anymore. I don't feel strongly about that, though. If you want to leave that as-is, fine with me. The patch actually is already split up into 8 smaller patches, each with their own commit message. They are just concatenated together into one file (i.e., in [https://git-scm.com/docs/git-am git am] format). > I have trouble to understand why `faketime` is needed now when building `go` given that we use `go` built without it for `obfs4proxy` and `meek` without any issues. "including those that arise here while compiling the Go runtime itself" should hold for the latter PTs as well, yet we don't need `faketime` in those cases. What is different between the `snowflake- client` and, say, the `obfs4proxy` case so that we need `faketime` for building `go` itself now? Are the problematic .o files plainly missing in `obfs4proxy`'s and `meek`s case? Or... I wondered about that too. I believe it is because of cgo. cgo invokes the system linker (i.e. Clang) and it is actually Clang that is the source of non-determinism, not go itself. See [https://dave.cheney.net/2016/01/18 /cgo-is-not-go here] for example: When you `import "C"` in your Go package, `go build` has to do a lot more work to build your code. Building your package is no longer simply passing a list of all the `.go` files in scope to a single invocation of `go tool compile`, instead: * The cgo tool needs to be invoked to generate the C to Go and Go to C thunks and stubs. * Your system C compiler has to be invoked for every C file in the package. * The individual compilation units are combined together into a single .o file. * The resulting .o file take a trip through the system linker for fix- ups against shared objects they reference. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22831#comment:4> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs