[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #25481 [Applications/Tor Browser]: Ship tor in Tor Browser nightly builds on Linux with Rust enabled



#25481: Ship tor in Tor Browser nightly builds on Linux with Rust enabled
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  task                                 |         Status:  new
 Priority:  High                                 |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-rbm, GeorgKoppen201804,          |  Actual Points:
  boklm201804, TorBrowserTeam201804R             |
Parent ID:  #25220                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------
Changes (by gk):

 * keywords:  tbb-rbm, GeorgKoppen201804, boklm201804, TorBrowserTeam201804
     => tbb-rbm, GeorgKoppen201804, boklm201804, TorBrowserTeam201804R


Comment:

 `bug_25481_v2` (https://gitweb.torproject.org/user/gk/tor-browser-
 build.git/commit/?h=bug_25481_v2&id=1f7c6f2ae24c9e79382bd1fdf380bbceac4e4d1c)
 has a patch for this bug up for review. Some notes might be in order,
 though:

 1) Rust needs CMake 3.4.3 at least + LLVM 3.9, and some compiler that
 supports C++-11. It turns out we want the first two anyway during the
 update of our macOS toolchain and g++4.7 is the minimum requirement
 outlined on the rust-lang website. So, we should be good, right? Alas, it
 turns our that's not the case. For one, not all parts we need to build are
 happy with g++ 4.7.2 which Wheezy ships, so we need our own compiler. But,
 two, even salvaging some of our LLVM build efforts are failing: using LLVM
 3.9 crashes the compiler during the cargo build step. See e.g.:
 {{{
   process didn't exit successfully:
 `/var/tmp/build/rustc-1.25.0-src/build/build/bootstrap/debug/rustc
 --crate-name lazycell vendor/lazycell/src/lib.rs --crate-type lib --emit
 =dep-info,link -C opt-level=2 -C metadata=1c971c2102b3dfa3 -C extra-
 filename=-1c971c2102b3dfa3 --out-dir
 /var/tmp/build/rustc-1.25.0-src/build/build/x86_64-unknown-linux-
 gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps --target x86_64
 -unknown-linux-gnu -L
 dependency=/var/tmp/build/rustc-1.25.0-src/build/build/x86_64-unknown-
 linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps -L
 dependency=/var/tmp/build/rustc-1.25.0-src/build/build/x86_64-unknown-
 linux-gnu/stage2-tools/release/deps --cap-lints allow` (signal: 11,
 SIGSEGV: invalid memory reference)
 }}}
 So, I worked around that by building LLVM during the rust compilation
 (which make the whole process taking significantly more time) using that
 version in turn.

 2) The current setup is building basically all the tools which come with
 the `rustc` source tarball. We might only need `rustc` and `cargo`, and
 one way to achieve that might be to split both and build them in separate
 projects. I am fine if we want to pursue this option later on after we got
 the basics working.

 3) There is a bunch of documentation that is getting built during normal
 compilation. I guess we can optimize that away later on and find other
 knobs to produce a smaller toolchain faster.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25481#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs