On Thu, Nov 16, 2023 at 2:54 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
> That being said, it's not unheard of for Postgres to make adjustments for
> third-party code (search for "pljava" in commits 62aba76 and f4aa3a1). I
> read the description of the pgrx problem [2], and I'm still trying to
> understand the scope of the issue. I don't think it's reasonable to expect
> someone building an extension to always use the exact same compiler that
> was used by the packager, but I also don't fully understand why different
> compilations of an inline function would cause problems.
>
> [0] https://postgr.es/m/CAFBsxsHG%3Dg6W8Mie%2B_NO8dV6O0pO2stxrnS%3Dme5ZmGqk--fd5g%40mail.gmail.com
> [1] https://postgr.es/m/CAFBsxsH1Yutrmu%2B6LLHKK8iXY%2BvG--Do6zN%2B2900spHXQNNQKQ%40mail.gmail.com
> [2] https://github.com/pgcentralfoundation/pgrx/issues/1298
>
We don't directly `#include` C into Rust, but use libclang to preprocess and
compile a wrapping C header into a list of symbols Rust will look for at link
time. Our failure is in libclang and how we steer it:
- The Clang-C API (libclang.so) cannot determine where system headers are.
- A clang executable can determine where system headers are, but our bindgen
may be asked to use a libclang.so without a matching clang executable!
- This is partly because system packagers do not agree on what clang parts
must be installed together, nor even on the clang directory's layout.
- Thus, it is currently impossible to, given a libclang.so, determine with
100% accuracy where version-appropriate system headers are and include them,
nor does it do so implicitly.
- Users cannot be expected to always have reasonable directory layouts, nor
always have one clang + libclang.so + clang/"$MAJOR"/include on the system.
- We have tried various solutions and have had several users report, by various
channels, that their builds are breaking, even after they charitably try out
the patches I offer in their CI. Especially after system updates.
The clang-sys and rust-bindgen crates committed a series of unfortunate hacks
that surprisingly work. But the only real solution is actually exposing the
C++ API for header searches to Clang-C, and then move that up the deps chain.
Perhaps libclang-18.so will not have this problem?
- Jubilee
