On Wed, 2025-02-05 at 13:10 -0500, Mike Gilbert wrote:

We usually want to invoke cc -E rather than cpp directly. We should not
rely on the quirk of tc-getCPP defaulting to "cc -E" when CPP is unset.

Resolves a warning when CPP is set to llvm-cpp, which does not accept
the -E option.

Closes: https://bugs.gentoo.org/949340
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
---
eclass/toolchain-funcs.eclass | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass index 0abed5b8d75e..754d23f91c06 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -1,4 +1,4 @@
-# Copyright 2002-2024 Gentoo Authors
+# Copyright 2002-2025 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

# @ECLASS: toolchain-funcs.eclass
@@ -900,7 +900,7 @@ tc-get-compiler-type() {
HAVE_GCC
#endif
'
- local res=$($(tc-getCPP "$@") -E -P - <<<"${code}")
+ local res=$($(tc-getCC "$@") -E -P - <<<"${code}")

case ${res} in
*HAVE_PATHCC*) echo pathcc;;
@@ -927,7 +927,7 @@ tc-is-clang() {
# compilers rather than maintaining a --version flag matrix, bug #335943.
_gcc_fullversion() {
local ver="$1"; shift
- set -- $($(tc-getCPP "$@") -E -P - <<<"__GNUC__ __GNUC_MINOR__ __GNUC_PATCHLEVEL__")
+ set -- $($(tc-getCC "$@") -E -P - <<<"__GNUC__ __GNUC_MINOR__ __GNUC_PATCHLEVEL__")
eval echo "${ver}"
}

@@ -960,7 +960,7 @@ gcc-micro-version() {
# Internal func. Based on _gcc_fullversion() above.
_clang_fullversion() {
local ver="$1"; shift
- set -- $($(tc-getCPP "$@") -E -P - <<<"__clang_major__ __clang_minor__ __clang_patchlevel__")
+ set -- $($(tc-getCC "$@") -E -P - <<<"__clang_major__ __clang_minor__ __clang_patchlevel__")
eval echo "${ver}"
}

@@ -1347,14 +1347,14 @@ tc-get-c-rtlib() {
# @FUNCTION: tc-get-ptr-size
# @RETURN: Size of a pointer in bytes for CHOST (e.g. 4 or 8).
tc-get-ptr-size() {
- $(tc-getCPP) -P - <<< __SIZEOF_POINTER__ ||
+ $(tc-getCC) -E -P - <<< __SIZEOF_POINTER__ ||
die "Could not determine CHOST pointer size"
}

# @FUNCTION: tc-get-build-ptr-size
# @RETURN: Size of a pointer in bytes for CBUILD (e.g. 4 or 8).
tc-get-build-ptr-size() {
- $(tc-getBUILD_CPP) -P - <<< __SIZEOF_POINTER__ ||
+ $(tc-getBUILD_CC) -E -P - <<< __SIZEOF_POINTER__ ||
die "Could not determine CBUILD pointer size"
}

I'm slightly unsure, but this has always confused me. If it works for you...

-----BEGIN PGP SIGNATURE-----

iQJFBAABCAAvFiEEPxcZ3tkwcedKm2a8EiZBXQDdMTcFAmejsF8RHGNoZXdpQGdl bnRvby5vcmcACgkQEiZBXQDdMTenNw/+LVwnn95GMiBWEhBrMkiTCNI6ZQ4LFXC3 wHWwQ6h1htz4MZFvG31BmLlM+yJ8CZTRrHhGGy67J+h2rA2rRzphBsekV8ErwQOK FUFZxGNL1wMxJ8oJG9+BPw2peE8rpsa40qdF4TQ/TERNmr0k4qn6Mwc2FD75sZlP QF2LPPEAfT8FJ2KkpBL04GaHbDUNDz4/fNe3Yj+y+kp/apc9dFUFRYUD/2S09VQe USBwYTCPylcQhWkoaI9CE2tyfuSSYYcbC6B8S+yTDID2yAaT0ETGEBF03RTIzgqm /Yf3c4xcTng+tyW1ltDyoWmHsHwR2vmavPqulgL7yQJrmUGge/SLqyoCXFgVvR2J P7TEIXTtYBIj/qHdjWAvNS0h6ccWSdnyJr5O/JgMTPhVlD6T963qQz04pXTCSoGb KZKaP/LDRTvTxnWn5/l9Qb+oxpthzM91RRpux96ZIvH3uXuhe9O1LxQHc5qbyffs pIjZiAFFuTSv59U0xnxztSsW0bKg7Sgu6KW668pNKPuIXfQhrL6ErfpUXRff1a6o BRRZS/jA9I5KmsGQCWC9ygC2TlUTILeEds3f12JC6c56msBGXcsMhyFAnUG6KRei I0r8t/ue3H7ckp8R5iX4KockfamSvRSuAABU9njjD/drS2v99LuMgVgGLFk3w5h8
tXWH6kRlIhg=
=z2R2
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Feb 05, 2025 at 01:10:10PM -0500, Mike Gilbert wrote:

We usually want to invoke cc -E rather than cpp directly. We should not
rely on the quirk of tc-getCPP defaulting to "cc -E" when CPP is unset.

I think it's a good change, but just to note it could break things
that relied on CPP being what's used.

Aka these don't have a proper way to say "test this compiler" and,
given it uses CPP, it's what I ended up setting:

CPP="${KERNEL_CC} -E" tc-is-clang ...

That's from nvidia-drivers ebuilds, which I'll fix real soon so no
need to worry about these. But I don't know what else may have done
this, not that I think it's going to be common.

I did something similar in linux-mod-r1.eclass but I took more
precaution there so it's not affected:

# for toolchain-funcs, uses CPP > CC but set both not to make assumptions
local CC=${KERNEL_CC} CPP="${KERNEL_CC} -E" LD=${KERNEL_LD}

I could cleanup the CPP bit if this is merged though. That it doesn't
use CC was confusing if anything thus needing a comment to explain
why it's being set.

Hopefully haven't forgot anything else I did, think wine & mingw things
are fine.
--
ionen

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmejtqsACgkQskQGsLCs QzSNLQgAm8Y24ivfWsuQttbtBi18bT8DyMZ+kfFDzs98pnTNH5Y/7sIEHkh8L8os MOa1sTPb1cLs92JfY+cW7EIyPvVkIDNepuqhPSBCKJq7RmzGIn2P5MC0Bz7FZZvY UW5YH6qi9BCYQXbBdp+o1VVrhg1Ls+SnWG7muaHJx5BY+70UKZgsbq4ul0ux0d14 VjoHe4XaiL2aACUeLUTEy49ueVtLSa1+8eMq3gfEHjq5g6/viMZD9mxCRjVLb9K0 90AVna3CExkrm6MjaDSt1N4sTuK056HSMHEjnl3mBJqtkzRev7DTVJ+oZtezz1Ts ys6jCc/RFI/fRRoNsIbJTXUOG+mgZA==
=B1eT
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Feb 5, 2025 at 2:06 PM Ionen Wolkens <ionen@gentoo.org> wrote:

On Wed, Feb 05, 2025 at 01:10:10PM -0500, Mike Gilbert wrote:

We usually want to invoke cc -E rather than cpp directly. We should not rely on the quirk of tc-getCPP defaulting to "cc -E" when CPP is unset.

I think it's a good change, but just to note it could break things
that relied on CPP being what's used.

Thanks for that reminder.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)