#3 FYI: I made some generalizations wrt cross-compilation

If you are interested I can open PRs for single files, just tell me.

Some changes wrt to generalizing cross-compilation. I have no idea why commits from yours are part of the PR. I successfully compiled firefox for arm on March 5th, but the last time I tried there was an error when building rust (the part where it builds llvm):

Scanning dependencies of target AttributeCompatFuncTableGen
make[3]: Leaving directory `/var/tmp/build/rustc-1.26.1-src/build/build/x86_64-unknown-linux-gnu/llvm/build'
make[3]: Entering directory `/var/tmp/build/rustc-1.26.1-src/build/build/x86_64-unknown-linux-gnu/llvm/build'
[ 19%] Building AttributesCompatFunc.inc...
../../bin/llvm-tblgen: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ../../bin/llvm-tblgen)
../../bin/llvm-tblgen: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by ../../bin/llvm-tblgen)
../../bin/llvm-tblgen: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ../../bin/llvm-tblgen)
make[3]: *** [lib/IR/AttributesCompatFunc.inc.tmp] Error 1
make[3]: Leaving directory `/var/tmp/build/rustc-1.26.1-src/build/build/x86_64-unknown-linux-gnu/llvm/build'
make[2]: *** [lib/IR/CMakeFiles/AttributeCompatFuncTableGen.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
[ 19%] Linking CXX executable ../../bin/yaml-bench
make[3]: Leaving directory `/var/tmp/build/rustc-1.26.1-src/build/build/x86_64-unknown-linux-gnu/llvm/build'
[ 19%] Built target yaml-bench
make[2]: Leaving directory `/var/tmp/build/rustc-1.26.1-src/build/build/x86_64-unknown-linux-gnu/llvm/build'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/build/rustc-1.26.1-src/build/build/x86_64-unknown-linux-gnu/llvm/build'
thread 'main' panicked at '
command did not execute successfully, got: exit code: 2

build script failed, must exit now', vendor/cmake/src/lib.rs:632:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
    finished in 467.628
failed to run: /var/tmp/build/rustc-1.26.1-src/build/build/bootstrap/debug/bootstrap build
Build completed unsuccessfully in 0:37:12
make: *** [all] Error 1

For now I focus on native compilation (https://notabug.org/hashashini/tor-browser-build-nativeAarch64) as I don't think it makes sense to have reproducible builds that are not reproducible on the target arch, thus kind of forcing people to get hold of a certain type of hardware.

Hi! Thanks for the PR! This is a project I mostly do on weekends, so I probably won't have time to review your PR for a few days.

That said, my initial impression is that I'll enthusiastically accept commits that improve the abstraction of different cross-compiled GNU/Linux targets, and will submit them to upstream Tor in the initial submission. Commits that are specific to non-armhf targets (such as aarch64, ppc64, and ppc64le) will also be welcomed by me, but I'll probably submit them to upstream Tor separately from the armhf submission, so that things are easier for Tor to review. So, as long as the non-armhf target commits are in separate commits from the commits that improve abstraction of cross-compiled targets, I don't see any problem.

I have no idea why commits from yours are part of the PR.

I suspect that you need to do a git rebase. I periodically rebase my repo against upstream Tor's repo, and you probably forked from my repo before my most recent rebase.

For now I focus on native compilation (https://notabug.org/hashashini/tor-browser-build-nativeAarch64) as I don't think it makes sense to have reproducible builds that are not reproducible on the target arch, thus kind of forcing people to get hold of a certain type of hardware.

Great! Adding support for non-x86 hosts is something I was intending to implement after non-x86 targets, since I agree with you that it's important. I just decided to spend my limited time on non-x86 targets first. Thank you for handling that work. In theory it should be possible to have reproducible builds that produce identical outputs independently of the host arch, although it's not clear to me how much effort will be involved in pulling that off.

Hi @hashashini,

A few pieces of feedback so far:

1. I notice that you've created a variable that's true whenever a cross-compile is happening, and used it to replace most instances of var/linux-arm. I think this is a good thing, but I'm skeptical that var/foreign is the best name for it. AFAIK, "foreign" is usually used in contexts like dpkg/apt, i.e. installing software from another architecture rather than compiling for it; typically the term used for compiling is "cross-compiling". What would you think about using var/cross-compile or something similar instead?
2. I notice that you've renamed var/crosstarget to target_tuple. Is there any reason you removed the var/ prefix? (I'm not super familiar with the internals of rbm, so I'm not entirely sure what the semantics of the var/ prefix are supposed to be.)
3. Given that the GCC, Rust, Go, and Debian ecosystems all have their own nomenclature for architectures, it might be a good idea to use a name like target-tuple-gcc instead of target-tuple. I know I ran into some build fails last week because I was mixing up GCC and Rust tuples; using more explicit naming would make it harder to screw stuff up.
4. Nit: it looks like the typical usage of rbm variables is to use hyphens rather than underscores. So, maybe we could use target-tuple rather than target_tuple?

Curious to hear your thoughts.

What would you think about using var/cross-compile or something similar instead?

Actually, given that this variable is being used specifically for cross-compiles where Linux is the target (the Windows and macOS targets are also cross-compiles but don't use this variable), probably it would make more sense to use var/linux-cross.

I notice that you've created a variable that's true whenever a cross-compile is happening.

It would be really nice to hear back from upstream wrt https://trac.torproject.org/projects/tor/ticket/12631#comment:28 since using gcc-cross for non-cross builds would make this variable superflous anyways. Otherwise I'm totally fine with using something else than var/foreign.

I notice that you've renamed var/crosstarget to target_tuple. Is there any reason you removed the var/ prefix?

I'm also not very familiar with rbm's internals, but as arch is specified above var, too, I had the impression target_tuple and cross_tuple rather belong there, as they partially even replace the use of arch in some projects. Though today I'd replace target_tuple simply with triple respectively cross_tuple with cross_triple to keep consistence with upstream (cf. https://notabug.org/JeremyRand/tor-browser-build/src/armhf-esr60/projects/rust/config lines 55 and following) But if we used gcc-cross for non-cross builds, the term cross_tuple respectively cross_triple of course wouldn't fit anymore.

Given that the GCC, Rust, Go, and Debian ecosystems all have their own nomenclature for architectures, it might be a good idea to use a name like target-tuple-gcc instead of target-tuple.

Yeah, this becomes especially obvious with ARMv7-A. As far as I can judge for now (combining my experience from my explorations based upon your repo and those from my initial attempts to build tor browser natively on aarch64) we'd best specify arch, rust_triple and gcc_triple - and yes I believe it also makes sense to specify go_arch in rbm.conf. Though I'm rather new to rbm and it is just my personal impression that rbm.conf is the place to specify the build and target environment. I believe that stuff shouldn't be dealt with in the separate projects.

Nit: it looks like the typical usage of rbm variables is to use hyphens rather than underscores. So, maybe we could use target-tuple rather than target_tuple?

I had exactly the contrary impression (cf. https://notabug.org/JeremyRand/tor-browser-build/src/armhf-esr60/rbm.conf lines 3-8,38,132,277,300,303 just to name a few) - I personally don't care, but afaik POSIX doesn't allow hyphens for variable names (cf. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_235)

Rebased my repo upon yours.

• var/foreign is now var/gcc-cross
• host_tuple is now var/rust_host
• rust_dist is now var/rust_dist
• target_tuple is now var/rust_target
• cross_tuple is now var/gcc_target

Still experiencing the same error as outlined in 1st post.

Note: in projects/cmake/config I had to set tag_gpg_id: 0 - otherwise the build fails complaining that v3.4.3 "is not a signed tag".

Concerning the use of arch for gcc-cross I think it would be best to use a new variable (e.g. kernel_arch). Apart from project/rust arch so far has been used in a rather different context, see my findings below. Its current use throughout upstream tor-brower-build IMO already indicates that this naming induces a certain degree of confusion.

Variables for targets that specify the build host:

var/rust_host:

• tuple matching the build host, for possible values see: https://forge.rust-lang.org/platform-support.html
• defaults to: x86_64-unknown-linux-gnu

var/container/arch:

• specifies the architecture of the build environment, i.e. of the container where projects are going to be compiled, for possible values see: https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#idm120
• needs to be compatible to the architecture of the build host
• defaults to: amd64

Variables for targets that specify the target OS and/or target system architecture:

kernel_arch:

• used to build a cross toolchain
• possible values see: linux kernel source, directory arch/ (https://www.kernel.org)

arch:

• related to firefox arch (ff_arch), possible values are: x86_64 i686 (cf. e.g. https://ftp.mozilla.org/pub/firefox/candidates/60.6.1esr-candidates/build1/)
• also used for windows targets, possible values are: x86_64 i686

var/rust_target:

• tuple that specifies the target platform, for possible values see: https://forge.rust-lang.org/platform-support.html

For cross-compilation support set:

var/gcc-cross:

• boolean, if set to 1 the build will utilize a cross-compilation toolchain

var/gcc_target:

• triple that specifies which architecture the cross-compiler should target, valid values are any outputs of 'gcc -dumpmachine'

var/apt_arch:

• indicates which architecture apt-get should support, for possible values see: https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#idm120

Hardware-independent variables:

var/container/suite:

• specifies which debian release the build env will be based on