Re: rust on 32-bit arm

[Greg Troxel <gdt%lexort.com@localhost>]

Havard Eidnes <he%NetBSD.org@localhost> writes:

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

Thanks for summarizing the situation for everyone!

> 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.

I think we should separate:

  A) pkgsrc is documented to support NetBSD 9 and NetBSD 10

from

  B) [for packages which do not have a good bootstrapping story] it is
  necessary to have a single binary bootstrap for NetBSD 9 and to use
  that on NetBSD 10 also

Certainly A is true, but A doesn't include "if we can't make something
work on 9 it's ok for it to just not work on 10 also".  It's a statement
that it's ok to break things on <=8 if it's necessary for progress, and
that filing bugs about <=8 without a clean fix isn't really ok.

I don't see why we couldn't build bootstraps per branch other than it
would take more time.

> 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.

As I read the PR, we *have* the bug in NetBSD 10.0 and netbsd-10 still,
and it's unclear if it is in netbsd-9, but fully agreed that just "don't
use TLS" is a great approach.

> 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.

Have you tried building on 9 with that change applied?

> 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.

That would be great!
If not, we should at least have the newer rust on earmv7hf-el/10.

Overall, I am wondering if it would be wise to have per-netbsd-branch
bootstraps, so that we avoid this kind of coupling.  I expect that the
future will continue to be messy.