Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects
Date
Msg-id 2871418.1777382981@sss.pgh.pa.us
Whole thread
In response to Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects  (John Naylor <johncnaylorls@gmail.com>)
Responses Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects
List pgsql-hackers
John Naylor <johncnaylorls@gmail.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



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: [PATCH] Fix stale relation close in sequence synchronization
Next
From: Ayush Tiwari
Date:
Subject: Re: [PATCH] Fix stale relation close in sequence synchronization