[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #12631 [Applications/Tor Browser]: Tor Browser for ARM architecture
#12631: Tor Browser for ARM architecture
-------------------------------------------+-------------------------------
Reporter: mttp | Owner: (none)
Type: project | Status:
| needs_revision
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: tbb-rbm, TorBrowserTeam201904 | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------+-------------------------------
Comment (by holin):
Replying to [comment:33 gk]:
> Replying to [comment:31 holin]:
> > My maint-8.0-armhf branch is now a bit cleaner and the x86 stuff
should build like it did originally without the arm changes interfering.
> >
> > I also uploaded a set of binaries to
> > https://sourceforge.net/projects/tor-browser-ports/
> > in case there's someone who'd like to test it out. So far, I've only
tested basic functionality on an ARM laptop running Debian stretch.
> >
> > Going forward, I'll probably import the changes over to master and try
to get nightly to build. However, in the grand scheme of things, Rust and
Firefox are heavy beasts and, I think, assuming tor project even considers
native build an option, supporting 32-bit build platforms is not the way
to go unless the said behemoths suddenly lose some serious weight.
>
> Yes, building on 32-bit is going to be harder an harder which is the
reason why Mozilla and we cross-compile our Linux 32-bit builds. So, while
I have the feeling that building natively would be easier here, it's not
the way we can go I think (while likely switch to Rust 1.33 for Firefox
ESR 68 and Firefox itself gets larger and not smaller).
>
> However, it would be interesting to see how this would look like cleaned
up a bit against our brand new `maint-8.5` branch, which e.g. ships
binutils 2.31.1. If you want to look at getting nightly builds going see
my previous comment for the snowflake situation.
>
> Is the result you get reproducible?
Playing catch-up, I haven't really checked reproducibility. What would be
the best way to do that? I don't really have an armada of ARM machines
with different setups here..
Regarding the arch naming, I think either using the gnu-triplet or osname
+ whatever the os calls the archs would be best. In case of linux, using
debian's naming would make sense to me. I changed the naming to linux-
armhf in my tree.
I've updated my changes to maint-8.5 and also added arm64 / aarch64
support. The arm64 port is sketchy because it would not build on jessie's
glibc (some problem with limited TLS slots) and, on the other hand,
stretch does not include hardening-wrapper anymore. The whole hardening-
wrapper thing, though, should imho be replaced with a local project that
could use apt in debian's recommended way to set the flags. Anyway, as a
consequence, arm64 build does not have hardening right now.
I had to change a few more projects because you (upstream) had gotten rid
of a generic linux target and replaced that with separate i686 and amd64
targets, so the arm archs had to have their own bits there as well.
My maint-8.5 changes for armhf and arm64 are at:
https://notabug.org/holin/tor-browser-build/src/maint-8.5-arm
Binaries still at:
https://sourceforge.net/projects/tor-browser-ports/
I'll keep on uploading binaries of releases to sourceforge, as time
permits, until official releases become available.
I've also briefly looked at adding a ppc64 (big endian) port, but looks
like firefox is in a sorry state on powerpc right now.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12631#comment:37>
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