Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Suppress "has no symbols" linker warnings on macOS.

  2. Fix two error messages in extended_stats_funcs.c

  1. [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Zhang Mingli <zmlpostgres@gmail.com> — 2026-01-29T06:35:34Z

    Hi,


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.

--
Zhang Mingli
HashData

  2. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Peter Eisentraut <peter@eisentraut.org> — 2026-02-04T14:54:35Z

    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.

  3. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-04T15:28:53Z

    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

  4. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Nathan Bossart <nathandbossart@gmail.com> — 2026-02-04T16:54:22Z

    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

  5. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-02-04T18:27:43Z

    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

  6. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Nathan Bossart <nathandbossart@gmail.com> — 2026-02-04T18:42:28Z

    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

  7. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-27T01:54:04Z

    Well, the latest macOS update added these warnings for aarch64:

ranlib: warning: 'libpgport_shlib.a(pg_cpu_x86.c.o)' has no symbols
ranlib: warning: 'libpgport_shlib.a(pg_popcount_x86.c.o)' has no symbols
ranlib: warning: 'libpgport_shlib.a(pg_cpu_x86.c.o)' has no symbols
ranlib: warning: 'libpgport_shlib.a(pg_popcount_x86.c.o)' has no symbols

I'm not seeing an easy way to pass -no_warning_for_no_symbols to ranlib, at
least with meson.  Hm...

-- 
nathan

  8. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-04-27T02:18:33Z

    Nathan Bossart <nathandbossart@gmail.com> writes:
> Well, the latest macOS update added these warnings for aarch64:
> ranlib: warning: 'libpgport_shlib.a(pg_cpu_x86.c.o)' has no symbols
> ranlib: warning: 'libpgport_shlib.a(pg_popcount_x86.c.o)' has no symbols
> ranlib: warning: 'libpgport_shlib.a(pg_cpu_x86.c.o)' has no symbols
> ranlib: warning: 'libpgport_shlib.a(pg_popcount_x86.c.o)' has no symbols

> I'm not seeing an easy way to pass -no_warning_for_no_symbols to ranlib, at
> least with meson.  Hm...

Yeah, we aren't even calling ranlib directly, it goes through 'ar'
which doesn't expose any such option.  In any case that'd necessarily
be an OS-specific option.

I previously suggested that we should teach the build systems not
to build the foo_x86 and foo_aarch64 modules when not on those
architectures.  That was shot down for reasons that made no great
amount of sense to me, but I think it'd be fairly easy and clean.

			regards, tom lane

  9. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-27T02:31:37Z

    On Sun, Apr 26, 2026 at 10:18:33PM -0400, Tom Lane wrote:
> I previously suggested that we should teach the build systems not
> to build the foo_x86 and foo_aarch64 modules when not on those
> architectures.  That was shot down for reasons that made no great
> amount of sense to me, but I think it'd be fairly easy and clean.

Yeah, AFAICT that's our best bet.  Will write it up in the morning.

-- 
nathan

  10. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-27T19:43:20Z

    On Sun, Apr 26, 2026 at 09:31:37PM -0500, Nathan Bossart wrote:
> On Sun, Apr 26, 2026 at 10:18:33PM -0400, Tom Lane wrote:
>> I previously suggested that we should teach the build systems not
>> to build the foo_x86 and foo_aarch64 modules when not on those
>> architectures.  That was shot down for reasons that made no great
>> amount of sense to me, but I think it'd be fairly easy and clean.
> 
> Yeah, AFAICT that's our best bet.  Will write it up in the morning.

Here's what I have so far.  Two notes:

* Since pg_popcount_aarch64.c only builds symbols when USE_NEON is defined,
I needed to teach the build code about that #define.  So, this patch
effectively moves USE_NEON and USE_SSE2 from c.h to pg_config.h, which
happens to be the first #include within c.h.  The reason that I bring this
up is because back-patching it seems a little scary, although I don't see
any concrete reasons it would be unsafe.

* pg_cpu_x86.c has a similar problem, which I haven't fixed yet.
Presumably a similar approach will work there.  I've added John Naylor to
this thread for his thoughts.

-- 
nathan

  11. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-27T20:03:37Z

    On Mon, Apr 27, 2026 at 02:43:20PM -0500, Nathan Bossart wrote:
> On Sun, Apr 26, 2026 at 09:31:37PM -0500, Nathan Bossart wrote:
>> On Sun, Apr 26, 2026 at 10:18:33PM -0400, Tom Lane wrote:
>>> I previously suggested that we should teach the build systems not
>>> to build the foo_x86 and foo_aarch64 modules when not on those
>>> architectures.  That was shot down for reasons that made no great
>>> amount of sense to me, but I think it'd be fairly easy and clean.
>> 
>> Yeah, AFAICT that's our best bet.  Will write it up in the morning.
> 
> Here's what I have so far.  Two notes:
> 
> * Since pg_popcount_aarch64.c only builds symbols when USE_NEON is defined,
> I needed to teach the build code about that #define.  So, this patch
> effectively moves USE_NEON and USE_SSE2 from c.h to pg_config.h, which
> happens to be the first #include within c.h.  The reason that I bring this
> up is because back-patching it seems a little scary, although I don't see
> any concrete reasons it would be unsafe.
> 
> * pg_cpu_x86.c has a similar problem, which I haven't fixed yet.
> Presumably a similar approach will work there.  I've added John Naylor to
> this thread for his thoughts.

Sorry, I noticed I was using USE_SSE2 for choosing whether to build
pg_popcount_x86.c, but the code in that file is actually surrounded by
HAVE_X86_64_POPCNTQ.  New patch attached.

-- 
nathan

  12. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    John Naylor <johncnaylorls@gmail.com> — 2026-04-28T06:18:22Z

    On Tue, Apr 28, 2026 at 2:43 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Sun, Apr 26, 2026 at 09:31:37PM -0500, Nathan Bossart wrote:
> > On Sun, Apr 26, 2026 at 10:18:33PM -0400, Tom Lane wrote:
> >> I previously suggested that we should teach the build systems not
> >> to build the foo_x86 and foo_aarch64 modules when not on those
> >> architectures.  That was shot down for reasons that made no great
> >> amount of sense to me, but I think it'd be fairly easy and clean.
> >
> > Yeah, AFAICT that's our best bet.  Will write it up in the morning.

The gift that keeps on giving. ;-)

> Here's what I have so far.  Two notes:
>
> * Since pg_popcount_aarch64.c only builds symbols when USE_NEON is defined,
> I needed to teach the build code about that #define.  So, this patch
> effectively moves USE_NEON and USE_SSE2 from c.h to pg_config.h, which
> happens to be the first #include within c.h.  The reason that I bring this
> up is because back-patching it seems a little scary, although I don't see
> any concrete reasons it would be unsafe.

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

(Ditto arm / aarch64) Likewise autoconf.ac could set e.g. PG_ARCH_OBJS
since it knows the host CPU as well. Some files could still guard on
USE_NEON or HAVE_X86_64_POPCNTQ, but at least they wouldn't get built
on the wrong arch. Would that be enough?

--
John Naylor
Amazon Web Services

  13. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-04-28T13:29:41Z

    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

  14. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-28T14:09:09Z

    On Tue, Apr 28, 2026 at 09:29:41AM -0400, Tom Lane wrote:
> 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...

I've been trying to avoid doing that, but it's a far simpler solution, and
in theory it should fix the problem for all platforms, too.  So, it's
probably the way to go.

-- 
nathan

  15. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-28T20:32:28Z

    On Tue, Apr 28, 2026 at 09:09:09AM -0500, Nathan Bossart wrote:
> On Tue, Apr 28, 2026 at 09:29:41AM -0400, Tom Lane wrote:
>> 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...
> 
> I've been trying to avoid doing that, but it's a far simpler solution, and
> in theory it should fix the problem for all platforms, too.  So, it's
> probably the way to go.

Here's a full set of patches for back-patching purposes.
protocol_openssl.c has a similar problem on older versions.  I suppose this
is the sort of thing I could back-patch all the way to v9.2.  Does anyone
feel strongly one way or the other about that?

-- 
nathan

  16. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-28T20:48:13Z

    On Tue, Apr 28, 2026 at 03:32:28PM -0500, Nathan Bossart wrote:
> Here's a full set of patches for back-patching purposes.
> protocol_openssl.c has a similar problem on older versions.  I suppose this
> is the sort of thing I could back-patch all the way to v9.2.  Does anyone
> feel strongly one way or the other about that?

Actually, v9.2-v12 don't have protocol_openssl.c, so I'd only need to
back-patch this to v13.

-- 
nathan

  17. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    John Naylor <johncnaylorls@gmail.com> — 2026-04-29T05:04:48Z

    On Wed, Apr 29, 2026 at 3:32 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Tue, Apr 28, 2026 at 09:09:09AM -0500, Nathan Bossart wrote:
> > On Tue, Apr 28, 2026 at 09:29:41AM -0400, Tom Lane wrote:
> >> 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...
> >
> > I've been trying to avoid doing that, but it's a far simpler solution, and
> > in theory it should fix the problem for all platforms, too.  So, it's
> > probably the way to go.
>
> Here's a full set of patches for back-patching purposes.

+1

-#endif           /* USE_NEON */
+#else
...
+#endif

Is the removal of the comment intentional?

-- 
John Naylor
Amazon Web Services

  18. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Peter Eisentraut <peter@eisentraut.org> — 2026-04-29T06:07:12Z

    On 28.04.26 22:32, Nathan Bossart wrote:
> Here's a full set of patches for back-patching purposes.
> protocol_openssl.c has a similar problem on older versions.  I suppose this
> is the sort of thing I could back-patch all the way to v9.2.  Does anyone
> feel strongly one way or the other about that?

Why should this be backpatched at all?

  19. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-04-29T13:58:58Z

    Peter Eisentraut <peter@eisentraut.org> writes:
> On 28.04.26 22:32, Nathan Bossart wrote:
>> Here's a full set of patches for back-patching purposes.
>> protocol_openssl.c has a similar problem on older versions.  I suppose this
>> is the sort of thing I could back-patch all the way to v9.2.  Does anyone
>> feel strongly one way or the other about that?

> Why should this be backpatched at all?

To silence those warnings.  If you're using a Mac for development,
they're pretty annoying.  And we have generally had a policy of
trying to silence warnings in still-interesting branches.

			regards, tom lane

  20. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-29T15:40:15Z

    On Wed, Apr 29, 2026 at 09:58:58AM -0400, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> Why should this be backpatched at all?
> 
> To silence those warnings.  If you're using a Mac for development,
> they're pretty annoying.  And we have generally had a policy of
> trying to silence warnings in still-interesting branches.

Right, I was under the impression that was project policy, or at least
allowed per project policy.

-- 
nathan

  21. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-29T15:41:29Z

    On Wed, Apr 29, 2026 at 12:04:48PM +0700, John Naylor wrote:
> -#endif           /* USE_NEON */
> +#else
> ...
> +#endif
> 
> Is the removal of the comment intentional?

It was, but I'll add them back before committing.

-- 
nathan

  22. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-04-29T15:44:14Z

    Nathan Bossart <nathandbossart@gmail.com> writes:
> On Wed, Apr 29, 2026 at 12:04:48PM +0700, John Naylor wrote:
>> Is the removal of the comment intentional?

> It was, but I'll add them back before committing.

+1, I found that annoying too.

			regards, tom lane

  23. Re: [BUG?] macOS (Intel) build warnings: "ranlib: file … has no symbols" for aarch64 objects

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-29T17:32:14Z

    Committed.

-- 
nathan