From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Jubilee Young <workingjubilee(at)gmail(dot)com> |
Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Hide exposed impl detail of wchar.c |
Date: | 2023-11-21 00:10:23 |
Message-ID: | 20231121001023.3ivje3c7cgg25f6k@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-11-16 17:11:03 -0800, Jubilee Young wrote:
> 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.
I remember battling this in the past, independent of rust :(
What I don't quite get is why SIMD headers are particularly more problematic
than others - there's other headers that are compiler specific?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-11-21 00:26:00 | Re: Show WAL write and fsync stats in pg_stat_io |
Previous Message | Andres Freund | 2023-11-20 23:58:55 | Re: Add recovery to pg_control and remove backup_label |