Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#12631: Tor Browser for ARM architecture
--------------------------------------+------------------------
 Reporter:  mttp                      |          Owner:  (none)
     Type:  project                   |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  tbb-rbm                   |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+------------------------

Comment (by JeremyRand):

 I've updated my rbm descriptors for (32-bit) ARM.  Currently all projects
 that typically are built for GNU/Linux targets are built for linux-arm,
 with the exception of fteproxy and snowflake (and their exclusive
 dependencies).  Since fteproxy and snowflake are optional components of
 Tor Browser, my inclination is to wait until the rest of this code is
 merged by Tor before I try to make fteproxy and/or snowflake build (they
 both seem more annoying to build than most of the other projects).

 The resulting Tor Browser binaries appear to work fine in my testing on my
 Asus C201 (I connected to Tor without bridges, navigated to a JS-heavy
 website, used that website for a few minutes, and exited); I didn't try
 using the pluggable transports.  There are a couple of minor bugs in the
 shell script that launches Tor Browser (I need to patch out the SSE2 check
 and make it set LD_LIBRARY_PATH), which should be easy for me to fix.

 So, at this point, the focus is shifting from "make it run on ARM" to
 "start cleaning up the code in order to make it possible to merge".  There
 are a number of things I want to do to improve code quality; the most
 obvious ones are (1) remove all the commented out code that's leftover
 from me throwing things at the build system to see what stuck; and (2)
 improve the abstraction, so that things that apply to any GNU/Linux cross-
 compiled target are cleanly separated from things that are specific to
 32-bit ARM.  If anyone wants to start looking at my code and suggest other
 things that I should clean up prior to a merge, by all means feel free.
 Or feel free to wait a few weeks for me to get the initial stages of
 cleanup out of the way; either way works for me.

 Regarding @c6h12o6's comment: I do not see cross-compiling as a competitor
 to having non-x86 rbm hosts; I see them as orthogonal.  My ultimate goal
 here is for rbm hosts using the set of {x86, ARM, and POWER} to all be
 able to reproduce the same hashes for targets within the set of {x86, ARM,
 and POWER}.  There's no reason why that shouldn't be possible, modulo
 compiler bugs and rbm descriptor bugs that should be fixed.  I personally
 find implementing cross-compile support to be easier given my skill set,
 and it seems like a good first step (hence it's what I'm implementing),
 but I would be highly supportive of efforts to add non-x86 rbm host
 support in addition to cross-compile support.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12631#comment:25>
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