Hi,
On 2022-10-16 16:45:24 -0400, Tom Lane wrote:
> I wrote:
> > I think the correct, future-proof fix is to s/REF/REF_P/ in the
> > grammar.
>
> Done like that, after which I found that the pre-v12 branches are
> compiling perfectly warning-free with the 13.0 SDK, despite nothing
> having been done about sprintf. This confused me mightily, but
> after digging in Apple's headers I understand it. What actually
> gets provided by <stdio.h> is a declaration of sprintf(), now
> with deprecation attribute attached, followed awhile later by
>
> #if __has_builtin(__builtin___sprintf_chk) || defined(__GNUC__)
> extern int __sprintf_chk (char * __restrict, int, size_t,
> const char * __restrict, ...);
>
> #undef sprintf
> #define sprintf(str, ...) \
> __builtin___sprintf_chk (str, 0, __darwin_obsz(str), __VA_ARGS__)
> #endif
>
> So in the ordinary course of events, calling sprintf() results in
> calling this non-deprecated builtin. Only if you "#undef sprintf"
> will you see the deprecation message.
Oh, huh. That's an odd setup... It's not like the the object size stuff
provides reliable protection.
> What I *am* seeing, in the 9.5 and 9.6 branches, is a ton of
>
> ld: warning: -undefined dynamic_lookup may not work with chained fixups
>
> apparently because we are specifying -Wl,-undefined,dynamic_lookup
> which the other branches don't do. That's kind of annoying,
> but it looks like preventing that would be way too invasive :-(.
> We'd added it to un-break some cases in the contrib transform
> modules, and we didn't have a better solution until v10 [1].
Hm - I think it might actually mean that transforms won't work with the new
macos relocation format, which is what I understand "chained fixups" to be.
Unfortunately it looks like the chained fixup stuff is enabled even when
targetting Monterey, even though it was only introduced with the 13 sdk (I
think). But it does look like using the macos 11 SDK sysroot does force the
use of the older relocation format. So we have at least some way out :/
Greetings,
Andres Freund
