pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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

>> Attempting to build "devel/cargo-c" from pkgsrc-HEAD on up-to-date
>> NetBSD/i386-10.0_BETA fails with:
>>
>> [...]
>> ===> Building for cargo-c-0.9.24
>>    Compiling faster-hex v0.8.0
>> error[E0425]: cannot find function `vectorization_support_no_cache_x86` in this scope
>>   --> /tmp/pkgsrc/devel/cargo-c/work/vendor/faster-hex-0.8.0/src/lib.rs:63:28
>>    |
>> 63 |         let val = unsafe { vectorization_support_no_cache_x86() };
>>    |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
>>
>> For more information about this error, try `rustc --explain E0425`.
>> error: could not compile `faster-hex` (lib) due to previous error
>> *** Error code 101
>
> 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.

Indeed.  Is it useful to report such bugs upstream, or has upstream
indicated they don't care about this kind of portability concern?

> I've locally added this patch:
>
> $NetBSD$
>
> Unify conditions for vectorization_support() use and definition.
>
> --- ../vendor/faster-hex-0.8.0/src/lib.rs.orig  2006-07-24 01:21:28.000000000 +0000
> +++ ../vendor/faster-hex-0.8.0/src/lib.rs
> @@ -43,7 +43,8 @@ pub(crate) enum Vectorization {
>  
>  #[inline(always)]
>  pub(crate) fn vectorization_support() -> Vectorization {
> -    #[cfg(all(any(target_arch = "x86", target_arch = "x86_64")))]
> +    #[cfg(all(any(target_arch = "x86", target_arch = "x86_64"),
> +              target_feature = "sse"))]
>      {
>          use core::sync::atomic::{AtomicU8, Ordering};
>          static FLAGS: AtomicU8 = AtomicU8::new(u8::MAX);
>
> And with this in place the build at least got past the faster-hex
> crate build:
>
> ...
>    Compiling gix-url v0.19.0
>    Compiling faster-hex v0.8.0
>    Compiling regex v1.9.4
> ...
>
> on NetBSD/i386 8.2 with rust 1.71.1 (from wip).
>
> Luckily, it doesn't look like I need to patch any cargo
> checksums, so I'll commit this patch shortly (I'll let the
> cargo-c build complete first).

Great.  I assume you'll commit it to what is in pkgsrc proper, too, so
this will be ok on the branch.


Home | Main Index | Thread Index | Old Index