Re: [PATCH v5 1/2] Makefile: add $(GITLIBS) prerequisite to osxkeychain
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 6, 2026, 19:52 UTC
- Message-ID
- <xmqqmrw3aoas.fsf@gitster.g>
- In-Reply-To
- <e0bb18ff0191de384ea3c947bf26ee07834782cb.1783358097.git.gitgitgadget@gmail.com>
"Shardul Natu via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 15 quoted lines
> From: Shardul Natu <snatu@google.com>
>
> When Rust is enabled, the git-credential-osxkeychain helper depends on
> Rust symbols compiled into $(RUST_LIB). While commit 522ea8ef7d
> ("osxkeychain: fix build with Rust") updated the linker command line to
> use $(LIBS), it omitted $(RUST_LIB) from the target prerequisite list.
> Without this prerequisite, running a parallel build ("make -j") from a
> clean working tree can fail because Make does not know to invoke Cargo
> to build libgitcore.a before linking git-credential-osxkeychain.
>
> All other core Git targets that link $(LIBS) already depend on
> $(GITLIBS), which bundles common-main.o, $(LIB_FILE), and $(RUST_LIB)
> when Rust is enabled. Add $(GITLIBS) as a prerequisite dependency to the
> git-credential-osxkeychain target to make it consistent with the rest of
> the codebase.I do not work with macOS but doesn't this change introduce a build/link failure?
Sorry if I am mistaken, but as far as I can see, $(GITLIBS) includes common-main.o (and it being .o, not .a, it is always included in the result), and git-credential-osxkeychain.c comes with its own main() function.
Using a list of things to link that contains common-main.o does not sound like a right thing to do; in other words, linking too many is just as bad as linking too little.