Subject: Re: Problems with 82e79c63642c, NOT_CONSTANT with sigfillset()

From: Junio C Hamano <[email-masked]>
Date: Mon, 05 May 2025 13:47:06 -0700

Torsten Bögershausen <[email-masked]> writes:

> There is a problem with the somewhat new
> commit 82e79c63642c introducing NOT_CONSTANT with sigfillset():
>
> Compiling on older (?) MacOs machine leads to this:
>     Undefined symbols for architecture x86_64:
>       "_false_but_the_compiler_does_not_know_it_", referenced from:
>           _start_command in libgit.a(run-command.o)
>
> What is the best thing to avoid this ?
>
> The introduced "false_but_the_compiler_does_not_know_it" triggers here
> because there is a proper prototype in signal.h and then a
> #define sigfillset() ...
> further down in the file, which can never fail.
>
> a) Define a sigfillset_or_die_if_needed macro,
>   which does what we have today, and is simply defined
>   as sigfillset() without any error checking for MacOs(some version)
> b) Revert the commit (and fix the conflicts)
> c) Anything better ?
>
> I have a raw patch for b), not fully cooked, as the commit message
> is the hardest part. Before sending that out:
> Are the thoughts about a better solution ?

How about figuring out why it does not work on your system?  

Namely, compiling compiler-tricks/not-constant.c should yield
compiler-tricks/not-constant.o and that should be "ar"ed into
libgit.a, just like config.o, connect.o, etc., so I cannot see how
your ld fails to find false_but_the_compiler_does_not_know_it when
it has no problem with say git_config or other global symbols.