On Thu, Nov 16, 2023 at 2:54 PM Nathan Bossart <nathandboss...@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
