rust on 32-bit arm

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

some of you have probably noticed that lang/rust is redirecting
to lang/rust176 for 32-bit arm.

The main reason for that is that I've not managed to get any
newer version of rust working on NetBSD/armv[67] version 9.0, and
since we still supports 9.x in pkgsrc we get where we are at the
moment.

For a long time I've worried that rust could possibly not
self-host anymore due to user-space virtual memory requirements.
Howeve,r the failure I'm seeing with cross-built binaries on
32-bit arm is "different".

Tobias Nygren commented that he managed to build rust 1.79.0 on
32-bit arm, but this was with NetBSD 10.0.  I've tested part of
this now, in that a cross-built 1.79.0 targeting earmv7hf using
tools from 10.0 and a 10.0 target dir via a modified rust-bin
package appears to work just fine (builds a working
sysutils/dua-cli).

For 64-bit arm we had a bug in the implementation of thread-
local storage (PR#58154), and since use of that is optional by
rust, and from a pkgsrc perspective we should support 9.x, I've
turned that option off in the rust target specification for
64-bit arm.

That bug is however specific to 64-bit arm.

However, Taylor Campbell found another change in ld.elf_so which
*might* explain why I'm seeing what I am, ref.

https://mail-index.netbsd.org/source-changes/2020/06/16/msg118407.html

And this change does affect 32-bit arm.  This is revision 1.45,
while netbsd-9 branched off 1.44 and has had 1.46 applied for
this file.

So...  I'm currently making an attempt via disabling the use of
thread-local storage also for the 32-bit arm NetBSD targets, and
we'll see where that leads -- whether we can get the same binary
to bootstrap 32-bit arm on NetBSD 9.x and 10.x (which is the
hope), and restore working newer rust on 32-bit arm on 9.x.

Regards,

- Håvard