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

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

>> If we add gcc-10, lang/rust packaged fine on
>> NetBSD/amd64 9.4
>>
>> May I commit?
>
> Almost always, that is wrong, because the requirement is some c++ std,
> not gcc10 itself.   I would not want to see this committed unless
> there's a link to evidence that there's some bug in gcc affecting <=9
> and fixed in 10.
>
> If it's "need c++17" then say that.
>
> The real question is what the real requirement is.

On principle you're right, of course, it would be best to know
the underlying root cause.  In some cases it can be as simple as
"the new compiler has fixed a bug which is present in the old
one", and in that case I would contest that stating "need c++17"
may actually be a circuituos route to force the use of a newer
gcc with the bugfix included.

Then there's the question of "expediency".  Is it better to leave
lang/rust un-buildable on a given OS-version / hardware
combination when there exists a known workaround?

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

Regards,

- Havard