Re: lang/rust with gcc10 (Re: diff from 2025-05-14 03:12 to 2025-05-17 10:36

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

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

>> Havard Eidnes <he%NetBSD.org@localhost> writes:
>> 
>>> Insisting on a full analysis of what the underlying root problem
>>> is is actually a quite tall order, especially given the size and
>>> complexity of lang/rust, so if that's going to be a barrier to
>>> making it buildable, that will probably cause it to be
>>> un-buildable for the given combination an extended time period if
>>> not indefinately.  I'll claim that is actually a worse way to
>>> deal with the issue than applying a known workaround..
>> 
>> Maybe so, but just adding the workaround without a comment with all of
>> the known information, and without explaining that it's the wrong
>> approach but nobody has any better ideas, is not an ok thing to do.
>> The next person to read the makefile will have no idea why.
>> 
>> So it could be explaining that while upstream documentations X, and gcc
>> says that Y should be sufficent, Y fails, and Z works, and we therefore
>> set it to Z, even though that's a kludge and masks a real, unknown bug.
>
> With reference to recent discussion on tech-pkg%NetBSD.org@localhost, would
> this diff satisfy the above?
>
> diff --git a/rust187/options.mk b/rust187/options.mk
> index 999196b96b..1ddbbdc0eb 100644
> --- a/rust187/options.mk
> +++ b/rust187/options.mk
> @@ -48,6 +48,18 @@ GCC_REQD+=	12
>  GCC_REQD+=	14
>  .endif
>  
> +# Apparently, using pkgsrc LLVM 19.x does not work on
> +# NetBSD/x86_64 9.x unless rust is built with a newer
> +# gcc than the platform-included 7.5.0.  Ref.
> +# https://gnats.netbsd.org/59435 and
> +# https://mail-index.netbsd.org/pkgsrc-users/2025/05/20/msg041603.html
> +# and following discussion.
> +.if empty(PKG_OPTIONS:Mrust-internal-llvm)
> +.  if ${MACHINE_PLATFORM:MNetBSD-9.*-x86_64}
> +GCC_REQD+=	10
> +.  endif
> +.endif
> +
>  #
>  # Use the internal copy of LLVM or the external one?
>  #
>
> I'm currently validating whether it fixes the issue in my case,
> and will need to rebuild at least curl, cmake, libunwind and llvm
> before that can be attempted.

(read your other note before this one..)

Indeed, I don't object to this as GCC_REQD abuse.   It is clear to the
reader that it's a workaround for a problem not understood.


The right fix is to release NetBSD 11 :-)  It will be late in March of
2026, and given our branch to release timeframes, I think we're behind
schedule already.