Re: [linux-next:master 9676/10599] ld.lld: error: undefined symbol: rust_build_error

["Alexandre Courbot" <acourbot@nvidia.com>]

On Fri Nov 21, 2025 at 11:30 PM JST, Gary Guo wrote:
> On Fri, 21 Nov 2025 15:21:45 +0100
> Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
>> On Fri, Nov 21, 2025 at 3:10 PM Alice Ryhl <aliceryhl@google.com> wrote:
>> >
>> > This kind of thing is why I keep saying build_error() is too fragile to
>> > be used at all.  
>
> The case here I think is a perfectly fine use case of `build_error` as
> it's completely by-value and does involve references. If compiler can't
> figure out, it's either a compiler bug or a source bug.
>
>> Adding `unsafe` blocks for things that should be able to be statically
>> known isn't great.
>> 
>> `build_assert!` is just too useful, so it is best to try to understand
>> what can be done, or find an equivalent solution. Gary et al. may have
>> some input here.
>
> I'd argue that these build issues actually helps us catch missed
> optimisations opportunities :)
>
> For this particular issue, I noticed that none of the functions
> involved here (`from_expr` and `fits_within`) are marked as `#[inline]`.
> I suspect after marking them as inline this case should be resolved.

The failing config features this setting:

    CONFIG_CC_OPTIMIZE_FOR_SIZE=y

I don't know whether this "CC" setting also affects Rust, but assuming
it does, we can very well imagine that at least one of
`from_expr`/`fits_within` does not get inlined, causing the compiler to
not be able to satisfy the `build_assert`.

If that's true, then this is an oversight of mine rather than a
fundamental problem, and could affect all architectures. I'll try to
reproduce the issue locally to test this theory.