Re: rust on 32-bit arm

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

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

That is true.  However, it is definately more messy, requiring
even more manual effort.  So my priority is that if we can set
things up so that a single bootstrap can be built on 9.x and 10.x
that is preferable.  I also have a suspcion that this goal is
within reach.

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

Yes, thanks for the correction.  So instead of insiting on a 9.x
or 10.x-based system "with the fix for this PR applied", from a
support perspective it "widens support" by turning off the "use
TLS" option.

We can re-visit this option once 10.0 is de-supported by pkgsrc,
which will take quite a while.

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

No.  And as above, the fix even if it works will not fix support
for systems pre-dating the fix.

If I manage to straighten out the general support for 32-bit arm
NetBSD systems by turning off thread-local storage, I can
possibly return to this testing item.

It's all about avoiding the bug and to continue to support
systems which don't have this change.

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

True, but in my view that would be the second-best solution.

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

If it's actually not needed, it would create a lot more work and
a lot more storage space need for the bootstraps.

Regards,

- Håvard