Re: Building cargo-c on netbsd-10/i386 fails

["John D. Baker" <jdbaker%consolidated.net@localhost>]

On Sun, 3 Sep 2023, Havard Eidnes wrote:

> Hmm...  I suspect this has something to do with which particular
> i386 CPU variant we build rust for, and that we've made an
> "unusual" choice...
> 
> Looking at the code, in work/vendor/faster-hex-0.8.0/src/lib.rs
> reveals that the use of vectorization_support_no_cache_x86() is
> conditional on
> 
>     #[cfg(all(any(target_arch = "x86", target_arch = "x86_64")))]
> 
> whereas the function definition just below is conditional on
> 
> #[target_feature(enable = "xsave")]
> #[cfg(all(
>     any(target_arch = "x86", target_arch = "x86_64"),
>     target_feature = "sse"
> ))]
> #[cold]
> 
> Our rust is built for the i486--netbsdelf GNU target (for maximal
> CPU support), and that might mean that our rust doesn't support
> the "sse" target feature.  This means that for our i386 rust this
> function ends up as "used but not defined".  Arguably this is a
> bug in the faster-hex cargo crate.

That would make sense.  I'm actually building this on amd64 hardware
running the i386 release with a PAE-enabled kernel for speed, more
memory, etc. (but it runs out of virtual addresses occasionally and
soft-wedges before it can use all of the 12GB physical RAM available).

I do absolutely want maximal CPU support as the machines that would
actually expect to run the resultant binaries are typically original
pentium and up.  Maybe a 486-ish thing just to see how it goes.

> I've locally added this patch:

I'll give it a try when my build host is available for package builds
again.  See my note above if that affects how things should be patched.

-- 
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net  OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645