Re: rust: NetBSD 9 earmv7, version selection, RUST_TYPE

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

Tobias Nygren <tnn%NetBSD.org@localhost> writes:

> On Tue, 06 May 2025 12:39:13 -0400
> Greg Troxel <gdt%lexort.com@localhost> wrote:
>
>> Thomas Klausner <wiz%gatalith.at@localhost> writes:
>> 
>> > Do I understand this correctly, that we should just switch NetBSD 9.x
>> > earm* to use binary rust, like in the attached diff?
>> >
>> > (Then we'd have one rust version on all platforms again, allowing some
>> > currently stuck package upgrades.)
>> 
>> Sure, but we should go further:
>> 
>>   Why is this limited to 9?   Can someone with a reasonable computer
>>   running armv7hf-el on NetBSD 10, like a RPI3 with 1G of RAM, expect
>>   that lang/rust will build?  I don't think so.
>> 
>>   Why is this limited to NetBSD?  I don't have the impression there's
>>   anything wrong with NetBSD arm.  Rather, it's that rust is
>>   fundamentally huge.   Can people running FreeBSD or Linux build
>>   lang/rust (not install a binary, build) on a machine with 1G of RAM?
>
> The reasonable thing to do for someone with such a computer would be to
> build their packages in a 32-bit chroot on a 64-bit machine with
> many CPU cores and at least 8GB of RAM. However, not even that is
> guaranteed to help here. The problem is not physical memory, it is that
> we start to hit the userland VA limit. evbarm uses a 2GB/2GB
> userland/kernel VA split. The only practical way to get rust onto such
> 32-bit ports is to cross-compile it.

I don't see that as reasonable, to need a big computer when a 1G machine
ought to be fine.  But that's rust, not about pkgsrc.

> i386 is different in that it has a 3GB/1GB userland/kernel VA split
> so it generally fairs better there. For now, at least.

i386 is also different in that most in-use computers, even on the i386
port, tend to have more RAM.

> It might be possible and even somewhat practical to build rust on earm
> with a 3GB/1GB VA split and some swap space. Some board configs do set
> KERNEL_BASE_EXT=0xc0000000 but that's not the default. Not sure why.

My position is that pkgsrc should be adjusted so that on any reasonable
instance of an architecture, 'make package' ends up working.

> I am not a fan of 3rd party binary packages but it seems it might be the
> only sane default for 2G/2G ports and it ok as long as the option
> to override the default is retained.

I don't like it either but the I allocate the wrongness of binary use to
the rust ecosystems.

As for defaults, that can certainly be spiffed up, but right now I am
not aware of a single report of rust building on earm*, so it feels a
bit theoretical.  Certainly it's easy to edit the mk file.