| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | John Naylor <johncnaylorls(at)gmail(dot)com> |
| Cc: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Zhang Mingli <zmlpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects |
| Date: | 2026-04-28 13:29:41 |
| Message-ID: | 2871418.1777382981@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
John Naylor <johncnaylorls(at)gmail(dot)com> writes:
> It'd be a bit unfortunate for those symbols to bleed out into the
> build system, so it seems best to minimize the need for that and do as
> much as possible with just architecture. src/port/meson.build could do
> instead
> if host_cpu == 'x86' or host_cpu == 'x86_64'
> pgport_sources += files(
> 'pg_cpu_x86.c',
> ...etc
This level of refinement is about what I was imagining for the
build systems. Otherwise, if we add any more platform sub-categories
to those files, we'll have to complicate the build systems to match.
I'm not sure if we need to care about suppressing these warnings to
a greater degree than that. My impression is that it won't be an
issue for macOS because of the uniformity of the underlying hardware.
If we do care, a low-tech solution could be to have a dummy symbol
declared in each file, along the lines of
#if HAVE_X86_64_POPCNTQ
// code for popcntq case
#elif HAVE_FROBNITZ
// code for frobnitz case
...
#else
/* prevent linker complaints about empty module */
extern int pg_cpu_x86_dummy_variable;
int pg_cpu_x86_dummy_variable = 0;
#endif
Actually then we'd not need to change the build systems either...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ayush Tiwari | 2026-04-28 13:34:52 | Re: [PATCH] Fix stale relation close in sequence synchronization |
| Previous Message | vignesh C | 2026-04-28 13:18:22 | Re: [PATCH] Fix stale relation close in sequence synchronization |