Each ebuild of dev-vcs/git currently has 2 instances (in src_compile() and src_install()) of this check: if [[ ${CHOST} == *-darwin* && ! tc-is-gcc ]]; then This does not call function tc-is-gcc (from toolchain-funcs.eclass), but checks if string tc-is-gcc is empty (it is always non-empty, so this check always returns false). Syntactically correct line would be: if [[ ${CHOST} == *-darwin* ]] && ! tc-is-gcc; then The conditional code is for building and installing git-credential-osxkeychain, but I do not know why it would not be possible to build git-credential-osxkeychain with GCC. In git-2.34.1, contrib/credential/osxkeychain/Makefile contains: CC = gcc So maybe ebuilds should actually just have: if [[ ${CHOST} == *-darwin* ]]; then
Historically, this could only build with clang, because of blocks support, which isn't in GCC. Today, it still isn't in GCC, and it still doesn't compile because the system frameworks contain constructs which GCC doesn't like: In file included from /Users/fabian/Gentoo-11.0i/MacOSX.sdk/System/Library/Frameworks/Security.framework/Headers/AuthSession.h:32, from /Users/fabian/Gentoo-11.0i/MacOSX.sdk/System/Library/Frameworks/Security.framework/Headers/Security.h:42, from git-credential-osxkeychain.c:4: /Users/fabian/Gentoo-11.0i/MacOSX.sdk/System/Library/Frameworks/Security.framework/Headers/Authorization.h:193:14: error: variably modified ‘bytes’ at file scope 193 | char bytes[kAuthorizationExternalFormLength]; | ^~~~~ git-credential-osxkeychain.c: In function ‘main’: git-credential-osxkeychain.c:171:17: warning: format not a string literal and no format arguments [-Wformat-security] 171 | die(usage); | ^~~ So, it must remain disabled, the check must be fixed though.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=538e155ff09754d737e20142b6519fb7b25c22d4 commit 538e155ff09754d737e20142b6519fb7b25c22d4 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2022-01-16 09:33:37 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2022-01-16 09:33:37 +0000 dev-vcs/git: fix osxkeychain conditional, thanks Arfrever Closes: https://bugs.gentoo.org/831276 Package-Manager: Portage-3.0.28, Repoman-3.0.3 Signed-off-by: Fabian Groffen <grobian@gentoo.org> dev-vcs/git/git-2.32.0-r1.ebuild | 4 ++-- dev-vcs/git/git-2.33.1.ebuild | 4 ++-- dev-vcs/git/git-2.34.1-r1.ebuild | 4 ++-- dev-vcs/git/git-2.34.1.ebuild | 4 ++-- dev-vcs/git/git-2.35.0_rc1.ebuild | 4 ++-- dev-vcs/git/git-9999-r1.ebuild | 4 ++-- dev-vcs/git/git-9999-r2.ebuild | 4 ++-- dev-vcs/git/git-9999-r3.ebuild | 4 ++-- dev-vcs/git/git-9999.ebuild | 4 ++-- 9 files changed, 18 insertions(+), 18 deletions(-)
Maybe you would be able to use Clang only for git-credential-osxkeychain when GCC is used for other parts of Git: if [[ ${CHOST} == *-darwin* ]] ; then ( if ! tc-is-clang ; then CC=${CHOST}-clang strip-unsupported-flags fi pushd contrib/credential/osxkeychain &>/dev/null || die git_emake CC=$(tc-getCC) CFLAGS="${CFLAGS}" \ || die "emake credential-osxkeychain" popd &>/dev/null || die ) fi ( and ) introduce subshell to keep changes in CC and CFLAGS local to this place.
unless I misunderstand, iff one uses clang, one can build the osx keychain integration. Else, with gcc, one cannot. Since clang really isn't an option at this point (it simply doesn't exist) we can also drop the entire block and never build the keychain integration. It comes from a time when we still had a functioning clang toolchain.
(In reply to Fabian Groffen from comment #4) > Since clang really isn't an option at this point (it simply doesn't exist) What do you mean exactly? sys-devel/clang has ~x64-macos in KEYWORDS. profiles/prefix/darwin/macos/packages contains *sys-devel/clang entry.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #5) > (In reply to Fabian Groffen from comment #4) > > Since clang really isn't an option at this point (it simply doesn't exist) > > What do you mean exactly? > > sys-devel/clang has ~x64-macos in KEYWORDS. > profiles/prefix/darwin/macos/packages contains *sys-devel/clang entry. You can read up on it if you wish (there's several bugs open for this) but at the very least, Clang-based bootstrap isn't possible, and when I last checked, at least building Clang on my Prefix didn't work. It may be fine for older Prefixes.
... and refgardless of that, I don't think it'1s a good idea to support a mix like you did with your CC-hack in the subshell. I'm happy to drop the whole construct, it's effectively dead code right now.
