This is an auto-filed bug because sys-kernel/linux-headers calls cc directly. The issue was originally discovered on s390, but it may be reproducible on other arches as well. If you think that a different summary clarifies the issue better, feel free to change it. Attached build log and emerge --info. NOTE: If you think it doesn't make sense fix these type of issues, I'd like to point out that won't be possible use a different CC implementation (like clang) by setting the CC variable. So this issue has been reproduced by setting the CC variable to s390x-ibm-linux-gnu-gcc and by removing the /usr/bin/cc - /usr/bin/gcc binaries.
Created attachment 642362 [details] build.log build log and emerge --info
That comes from kernel-2.eclass. I think kernel-2.eclass should set something like HOSTCC="$(gc-getBUILD_CC)".
Ended up being easier that I though. The following seems to be enough: --- a/eclass/kernel-2.eclass +++ b/eclass/kernel-2.eclass @@ -712,6 +712,7 @@ env_setup_xmakeopts() { elif type -p ${CHOST}-ar > /dev/null ; then xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-" fi + xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)" export xmakeopts } Sent fore review as: https://archives.gentoo.org/gentoo-dev/message/6a616f98f142191ff3739998bd3136bb Lightly tested for native and cross cases.
(In reply to Sergei Trofimovich from comment #3) > Ended up being easier that I though. The following seems to be enough: > > --- a/eclass/kernel-2.eclass > +++ b/eclass/kernel-2.eclass > @@ -712,6 +712,7 @@ env_setup_xmakeopts() { > elif type -p ${CHOST}-ar > /dev/null ; then > xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-" > fi > + xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC)" > export xmakeopts > } > > Sent fore review as: > https://archives.gentoo.org/gentoo-dev/message/ > 6a616f98f142191ff3739998bd3136bb > > Lightly tested for native and cross cases. ++
Pushed as https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3dd41142d73f41e2528eefa32e760fc3083001ee