| From: | harrisontbooth(at)gmail(dot)com |
|---|---|
| To: | Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> |
| Cc: | Christoph Berg <myon(at)debian(dot)org>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: meson vs. llvm bitcode files |
| Date: | 2026-10-13 23:14:05 |
| Message-ID: | CAAH-eSX_OniTafzLjiis+LsgnicS5JSuiJriQw_B2wEHM_q4mA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Testing v15 with LLVM enabled on Windows, I hit a configure failure:
citext, hstore, intarray, ltree and pg_trgm include Windows resource
objects in their bitcode source lists, which fs.parent() rejects.
The attached patch saves each C-source list before adding resources.
DLL resources remain intact, and all 27 C files remain in bitcode
generation.
A focused configure test fails before the change and passes afterward.
With my local header/export supplement also applied, fresh LLVM
configuration and all 27 bitcode files plus five ThinLTO indexes build
successfully using MinGW x64 on an ARM64 host. Full-server JIT SQL
remains untested.
Let me know if you'd prefer another approach to separating the resource inputs.
Best,
Harrison
| Attachment | Content-Type | Size |
|---|---|---|
| CF5671-v15-Windows-C-source-bitcode-only-v1.patch | text/x-patch | 2.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Geier | 2026-10-13 23:14:14 | Re: use radix tree for bitmap heap scan |
| Previous Message | David Geier | 2026-10-13 23:02:20 | Re: Improving scalability of Parallel Bitmap Heap/Index Scan |