Building rustc on armv7: rust build is Bloated


I'm doing my best to keep rust building on various NetBSD ports. One of them is using 32-bit armv7, but it now appears that rust from version 1.51.0 is no longer possible to build natively on such a platform, due to virtual memory exhaustion:

   Compiling rustc_middle v0.0.0 (/usr/pkgsrc/wip/rust/work/rustc-1.51.0-src/compiler/rustc_middle)
memory allocation of 72 bytes failed

The VM resources available on this platform are largely given by the maximum data segment size, which was bumped a while back with this comment:

Bump MAXDSIZ from 1536 to 1836.
1836 is 2048-128(MAXTSIZ)-64(MAXSSIZ).

(measured in MB) and if I've understood correctly, other platform constraints makes only 2GB available for user processes.

I have managed to build rust natively on this platform up to and including 1.50.0.


  1. where should I have brought up this theme? (None of the categories in the drop-down menu appear to be a particularly good fit...)

  2. is there something which can be done to shoe-horn it in to fit still? I've already limited LLVM to only do the ARM target on this platform, for instance, and various debug info options are already turned off.

  3. is the project of keeping rust self-hosting on such a platform a lost cause? ("Does anyone else care?")




You could try using -j1 to only run a single compile job at a time, thereby reducing memory consumption. I believe that even with -j1 some crates like rustc_middle need more than 2GB to compile though.

Oh, I'm already using -j1 for the build, and have been for some time.

I'm also building with these options:

CONFIGURE_ARGS+=        --disable-debug
CONFIGURE_ARGS+=        --disable-debug-assertions
CONFIGURE_ARGS+=        --disable-llvm-release-debuginfo
CONFIGURE_ARGS+=        --debuginfo-level=0
CONFIGURE_ARGS+=        --debuginfo-level-rustc=0
CONFIGURE_ARGS+=        --debuginfo-level-std=0
CONFIGURE_ARGS+=        --debuginfo-level-tools=0
CONFIGURE_ARGS+=        --debuginfo-level-tests=0
CONFIGURE_ARGS+=        --set llvm.targets="ARM"

So ... the question remains.

I can't even build a release version of amalgamated sqlite (massive pure single C file) on a PicoZed platform (1G RAM) because it runs out of memory (without tweaks). I've started coming to terms with the idea that targeting 32-bit platforms nowadays requires cross-compilation. :neutral_face:

I noticed that some crates which support dynamic linking to external libraries when building natively will statically link when cross-compiling (for understandable reasons, I guess), which is not optimal when you're having trouble fitting everything in a system image and want to reuse dynamic libs as much as possible.

Does NetBSD support running 32-bit armv7 userspace on a 64-bit kernel? Does it give a full 4GB address space to each 32-bit user process in that case, as x86_64 Linux does for 32-bit x86 user processes? (Though, at that point, you could also just cross-compile.)

If you have hardware with enough memory, you could attempt to teach 32-bit NetBSD to support a 4GB/4GB split or something close to one, which would be less efficient (switching address spaces on every syscall) but allow a full 4GB for userspace.

If neither of those options appeals to you, and you do care about building Rust natively on the platform rather than cross-compiling to it, then I would suggest contributing to the ongoing efforts to simplify and split up rustc_middle; those efforts would help improve the experience of building Rust for all developers, since not everyone has enough memory (and since it's nice to not have to use -j1).


Note that the PR that drastically reduced memory required to build rustc_middle and query system has been merged only 2 months ago:

If the labels are correct, it will be released in 1.52. You could try building beta or nightly to see if it helps in your case (nightly should be better, because there were some followup improvements).


Yes, NetBSD supports running 32-bit armv7 userspace on a 64-bit kernel, and that is the avenue I am now pursuing (on an emulated 64-bit arm system, so not the quickest). The purist in me however says this isn't "native" :slight_smile:

Oh, that's excellent news that 1.52 should see improvements in this area! Unfortunately, building a release and building "nightly" is drastically different, and my current build setup isn't set up to be able to build "nightly", so I'll just have to wait till 1.52 is out, which is actually fine by me.

I didn't realize 1.52 is out in 2 days, so that seems fine :wink:

1 Like