tboegi@xxxxxx writes: > From: Torsten Bögershausen <tboegi@xxxxxx> > > Compiling/linking 82e79c63642c on an 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) > > The linker doesn't seem to pick up the symbol: > "false_but_the_compiler_does_not_know_it_" > > Initializing the variable to 0 fixes the problem: > The symbol type changes from 'C' to 'S' and is picked up by the linker. > > Helped-by: Koji Nakamaru <koji.nakamaru@xxxxxxxx> > Signed-off-by: Torsten Bögershausen <tboegi@xxxxxx> > --- > compiler-tricks/not-constant.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks, both. The alleged ld bug and this fix I can sort of believe. The resulting object file from the original code would not have any data, but just declares a BSS symbol in common, which may be unusual, and this forces us to have an explicit initialization data. Just for reference (as the proposed log message refers to an "older macOS"), do we know if the toolchain on a more recent release of macOS work without this workaround already? It may be nice to tell users what version they need to avoid the same issue in their own program. Will queue. Thanks. > Koji Nakamaru: Thanks for the digging. > This patch fixes the problem here - as a side note, > the change in Makefile alone doesn't help. > > > diff --git a/compiler-tricks/not-constant.c b/compiler-tricks/not-constant.c > index 1da3ffc2f5..9fb4f275b1 100644 > --- a/compiler-tricks/not-constant.c > +++ b/compiler-tricks/not-constant.c > @@ -1,2 +1,2 @@ > #include <git-compat-util.h> > -int false_but_the_compiler_does_not_know_it_; > +int false_but_the_compiler_does_not_know_it_ = 0;
