Обсуждение: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

On 29.01.26 07:35, Zhang Mingli wrote:
> I'm building the master branch (commit 740a1494f4bf) on macOS (Intel 
> Core i7) and encountered the following warnings during the make process:
> 
> 
> 
> /Applications/Xcode.app/Contents/Developer/Toolchains/ 
> XcodeDefault.xctoolchain/usr/bin/ranlib: file: 
> libpgport.a(pg_popcount_aarch64.o) has no symbols
> /Applications/Xcode.app/Contents/Developer/Toolchains/ 
> XcodeDefault.xctoolchain/usr/bin/ranlib: file: 
> libpgport_shlib.a(pg_popcount_aarch64_shlib.o) has no symbols
> /Applications/Xcode.app/Contents/Developer/Toolchains/ 
> XcodeDefault.xctoolchain/usr/bin/ranlib: file: 
> libpgport_srv.a(pg_popcount_aarch64_srv.o) has no symbols
> 
> 
> The build completes successfully and the compiled binaries appear to 
> function correctly.
> These warnings appear to be related to the recent AArch64 (pg_popcount) 
> optimization commits (possibly 79e232ca013c and fbe327e5b465d). It seems 
> that on my Intel-based macOS system, the build process is generating 
> empty or placeholder object files for the AArch64-specific implementations.
> While there is no functional impact in my environment, I'm reporting 
> this to ensure it's noted, as other macOS/Intel users might encounter 
> the same warnings during their build.

Probably not worth fixing, since this is an obsolescent platform.

The opposite situation also exists: On macOS ARM, an empty 
pg_popcount_x86.c gets built, but apparently that linker doesn't warn 
about that.

Peter Eisentraut <peter@eisentraut.org> writes:
> On 29.01.26 07:35, Zhang Mingli wrote:
>> These warnings appear to be related to the recent AArch64 (pg_popcount) 
>> optimization commits (possibly 79e232ca013c and fbe327e5b465d). It seems 
>> that on my Intel-based macOS system, the build process is generating 
>> empty or placeholder object files for the AArch64-specific implementations.
>> While there is no functional impact in my environment, I'm reporting 
>> this to ensure it's noted, as other macOS/Intel users might encounter 
>> the same warnings during their build.

> Probably not worth fixing, since this is an obsolescent platform.

Yeah.  My Intel Mac buildfarm animal (longfin) has been showing this
for some time, but there's no corresponding warning on its ARM Mac
brethren (sifaka/indri).  I doubt it's worth fixing just to get
rid of the warning.  Although if a fix arises organically out of the
nearby thread about popcount refactoring, that would be okay here...

            regards, tom lane

On Wed, Feb 04, 2026 at 10:28:53AM -0500, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> On 29.01.26 07:35, Zhang Mingli wrote:
>>> These warnings appear to be related to the recent AArch64 (pg_popcount) 
>>> optimization commits (possibly 79e232ca013c and fbe327e5b465d). It seems 
>>> that on my Intel-based macOS system, the build process is generating 
>>> empty or placeholder object files for the AArch64-specific implementations.
>>> While there is no functional impact in my environment, I'm reporting 
>>> this to ensure it's noted, as other macOS/Intel users might encounter 
>>> the same warnings during their build.
> 
>> Probably not worth fixing, since this is an obsolescent platform.
> 
> Yeah.  My Intel Mac buildfarm animal (longfin) has been showing this
> for some time, but there's no corresponding warning on its ARM Mac
> brethren (sifaka/indri).  I doubt it's worth fixing just to get
> rid of the warning.  Although if a fix arises organically out of the
> nearby thread about popcount refactoring, that would be okay here...

Hm.  The options I see for fixing this seem to be:

* Pass -no_warning_for_no_symbols flag on this platform, but that option
might not be available in older toolchains.

* Add a random symbol to this file.  That seems like a hack.

* Add build logic to only compile this file when necessary.  I've been
trying to get rid of complexity here, so this feels like a step backwards.

IMHO none of these options seem worth the effort to fix a warning on an
obsolescent platform, so my vote is to do nothing for now.

-- 
nathan

Nathan Bossart <nathandbossart@gmail.com> writes:
> Hm.  The options I see for fixing this seem to be:

> * Pass -no_warning_for_no_symbols flag on this platform, but that option
> might not be available in older toolchains.

> * Add a random symbol to this file.  That seems like a hack.

> * Add build logic to only compile this file when necessary.  I've been
> trying to get rid of complexity here, so this feels like a step backwards.

> IMHO none of these options seem worth the effort to fix a warning on an
> obsolescent platform, so my vote is to do nothing for now.

The idea I'd had was to simply merge pg_popcount_aarch64.c
and pg_popcount_x86.c into one file.  Since each one is basically
one giant #ifdef block conditioned on a different symbol, they'd not
interfere.  But I wouldn't propose this unless it made sense from
a code-structure viewpoint, and I'm not sure it does.  It could
make sense if there was some code that could be shared, but I'm
not seeing much.

            regards, tom lane

On Wed, Feb 04, 2026 at 01:27:43PM -0500, Tom Lane wrote:
> The idea I'd had was to simply merge pg_popcount_aarch64.c
> and pg_popcount_x86.c into one file.  Since each one is basically
> one giant #ifdef block conditioned on a different symbol, they'd not
> interfere.  But I wouldn't propose this unless it made sense from
> a code-structure viewpoint, and I'm not sure it does.  It could
> make sense if there was some code that could be shared, but I'm
> not seeing much.

Yeah, even after the upcoming code simplification I'm working on, I'm not
sure that makes sense.

-- 
nathan