Message-ID: <CANiq72mUu9V0tAFRYju5=B9-EZ9hbPVMabKJvHm67n7BgSVQXw@mail.gmail.com>
Date: Tue, 12 Nov 2024 12:42:55 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Miguel Ojeda <ojeda@...nel.org>
Cc: Alex Gaynor <alex.gaynor@...il.com>, Nathan Chancellor <nathan@...nel.org>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, rust-for-linux@...r.kernel.org, 
	Nick Desaulniers <ndesaulniers@...gle.com>, Bill Wendling <morbo@...gle.com>, 
	Justin Stitt <justinstitt@...gle.com>, llvm@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	patches@...ts.linux.dev, Ben Beasley <code@...icinmybrain.net>, 
	NoisyCoil <noisycoil@...anota.com>, Matthias Geiger <werdahias@...eup.net>, 
	Masahiro Yamada <masahiroy@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, 
	Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH v2] rust: warn on bindgen < 0.69.5 and libclang >= 19.1

On Mon, Nov 11, 2024 at 9:16 PM Miguel Ojeda <ojeda@...nel.org> wrote:
>
> When testing a `clang` upgrade with Rust Binder, Alice encountered [1] a
> build failure caused by `bindgen` not translating some symbols related to
> tracepoints. This was caused by commit 2e770edd8ce1 ("[libclang] Compute
> the right spelling location") changing the behavior of a function exposed
> by `libclang`. `bindgen` fixed the regression in commit 600f63895f73
> ("Use clang_getFileLocation instead of clang_getSpellingLocation").
>
> However, the regression fix is only available in `bindgen` versions
> 0.69.5 or later (it was backported for 0.69.x). This means that when
> older bindgen versions are used with new versions of `libclang`, `bindgen`
> may do the wrong thing, which could lead to a build failure.
>
> Alice encountered the bug with some header files related to tracepoints,
> but it could also cause build failures in other circumstances. Thus,
> always emit a warning when using an old `bindgen` with a new `libclang`
> so that other people do not have to spend time chasing down the same
> bug.
>
> However, testing just the version is inconvenient, since distributions
> do patch their packages without changing the version, so I reduced the
> issue into the following piece of code that can trigger the issue:
>
>     #define F(x) int x##x
>     F(foo);
>
> In particular, an unpatched `bindgen` will ignore the macro expansion
> and thus not provide a declaration for the exported `int`.
>
> Thus add a build test to `rust_is_available.sh` using the code above
> (that is only triggered if the versions appear to be affected), following
> what we did for the 0.66.x issue.
>
> Moreover, I checked the status in the major distributions we have
> instructions for:
>
>   - Fedora 41 was affected but is now OK, since it now ships `bindgen`
>     0.69.5.
>
>     Thanks Ben for the quick reply on the updates that were ongoing.
>
>     Fedora 40 and earlier are OK (older `libclang`, and they also now
>     carry `bindgen` 0.69.5).
>
>   - Debian Sid was affected but is now OK, since they now ship a patched
>     `bindgen` binary (0.66.1-7+b3). The issue was reported to Debian by
>     email and then as a bug report [2].
>
>     Thanks NoisyCoil and Matthias for the quick replies. NoisyCoil handled
>     the needed updates. Debian may upgrade to `bindgen` 0.70.x, too.
>
>     Debian Testing is OK (older `libclang` so far).
>
>   - Ubuntu non-LTS (oracular) is affected. The issue was reported to Ubuntu
>     by email and then as a bug report [3].
>
>     Ubuntu LTS is not affected (older `libclang` so far).
>
>   - Arch Linux, Gentoo Linux and openSUSE should be OK (newer `bindgen` is
>     provided). Nix as well (older `libclang` so far).
>
> This issue was also added to our "live list" that tracks issues around
> distributions [4].
>
> Cc: Ben Beasley <code@...icinmybrain.net>
> Cc: NoisyCoil <noisycoil@...anota.com>
> Cc: Matthias Geiger <werdahias@...eup.net>
> Link: https://lore.kernel.org/rust-for-linux/20241030-bindgen-libclang-warn-v1-1-3a7ba9fedcfe@google.com/ [1]
> Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086510 [2]
> Link: https://bugs.launchpad.net/ubuntu/+source/rust-bindgen-cli/+bug/2086639 [3]
> Link: https://github.com/Rust-for-Linux/linux/issues/1127 [4]
> Co-developed-by: Alice Ryhl <aliceryhl@...gle.com>
> Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
> Signed-off-by: Miguel Ojeda <ojeda@...nel.org>
> ---
> We would like to put this into the merge window, or ideally very soon after as a
> "fix" (it is not really a fix, but it is very convenient for people wondering
> why their toolchain may not work, especially if tracepoints land in the merge
> window as expected).
>
> v2 (based on Alice's v1):
>   - Fixed libclang version number (we use a different `get_canonical_version`
>     that returns one more digit).
>   - Added build test -- now we can detect binaries like Debian's that are
>     patched but do not change the version number.
>   - Added tests.
>   - Explained the current status of the distributions in the commit message.

Cc'ing Kbuild too, so that they are aware, just in case -- sorry, I
should have done that in the patch itself yesterday:

    https://lore.kernel.org/rust-for-linux/20241111201607.653149-1-ojeda@kernel.org/

Cheers,
Miguel

Powered by blists - more mailing lists