Re: [PATCH 1/1] Fix compilation on mac with Xcode >= 11.4.

On Thu, Nov 19, 2020 at 6:04 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> James Hilliard <james(dot)hilliard1(at)gmail(dot)com> writes:
> > Hmm, maybe it's a more recent issue then, I took the version number
> > from the qt patch assuming it was the same issue, I hit it trying to build
> > master on Xcode 12.2 Build version 12B45b on Catalina version 10.15.7.
>
> Hm, maybe you're using some unusual configure options or weird build
> environment?
>
> The cases we've got in the buildfarm are Xcode 12.0 on Catalina (10.15.7)
> and Xcode 12.2 on Big Sur (11.0.1 ... although that one is ARM not Intel).
> Maybe you're found some corner case in between those, but I guess it's
> more likely due to a configuration choice.
I guess to verify one could try compiling with Xcode 12.2 on catalina 10.15.7.

This looks to be the function using the missing symbols, called by
FD_SET in postgres:

__header_always_inline int
__darwin_check_fd_set(int _a, const void *_b)
{
#ifdef __clang__
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunguarded-availability-new"
#endif
if ((uintptr_t)&__darwin_check_fd_set_overflow != (uintptr_t) 0) {
#if defined(_DARWIN_UNLIMITED_SELECT) || defined(_DARWIN_C_SOURCE)
return __darwin_check_fd_set_overflow(_a, _b, 1);
#else
return __darwin_check_fd_set_overflow(_a, _b, 0);
#endif
} else {
return 1;
}
#ifdef __clang__
#pragma clang diagnostic pop
#endif
}

Which is located here:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk/usr/include/sys/_types/_fd_def.h

The header file indicates the missing symbols are only available in 11.0 and up:
int __darwin_check_fd_set_overflow(int, const void *, int)
__API_AVAILABLE(macosx(11.0), ios(14.0), tvos(14.0), watchos(7.0));

So I think it's fairly clear what's happening now, the linker would normally use
the system libraries to determine that those missing symbols are
weakly linked, but since
the base OS is too old that fails unless we tell the linker where to
look(in the SDK).
>
> regards, tom lane