On sys-devel/gcc-config[-native-symlinks] system gtk+ fails to build in configure phase as: """ ... checking dependency style of x86_64-pc-linux-gnu-gcc -m32... none checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -m32 -E checking for gcc... no checking for cc... no checking for cl.exe... no configure: error: in `/tmp/portage/x11-libs/gtk+-3.24.20/work/gtk+-3.24.20-abi_x86_32.x86': configure: error: no acceptable C compiler found in $PATH See `config.log' for more details """ sys-devel/gcc-config[-native-symlinks] removes default 'cc' and 'gcc' symlinks and relies on ebuilds passing CC/CXX variables. In this case CC_FOR_BUILD variable is not set in the ebuild. The following seems to be enough to get gtk+ going again: --- a/x11-libs/gtk+/gtk+-3.24.20.ebuild +++ b/x11-libs/gtk+/gtk+-3.24.20.ebuild @@ -5,7 +5,7 @@ EAPI=6 GNOME2_LA_PUNT="yes" GNOME2_EAUTORECONF="yes" -inherit flag-o-matic gnome2 multilib virtualx multilib-minimal +inherit flag-o-matic gnome2 multilib virtualx multilib-minimal toolchain-funcs DESCRIPTION="Gimp ToolKit +" HOMEPAGE="https://www.gtk.org/" @@ -131,6 +131,8 @@ src_prepare() { eapply "${FILESDIR}"/${PN}-3.22.20-libcloudproviders-automagic.patch gnome2_src_prepare + + export CC_FOR_BUILD="$(tc-getBUILD_CC)" } multilib_src_configure() {
Please explain why should it be set by a specific ebuild for a standard use of AX_PROG_CC_FOR_BUILD macro? Shouldn't it be set by portage or the user killing cc?
(In reply to Mart Raudsepp from comment #1) > Please explain why should it be set by a specific ebuild for a standard use > of AX_PROG_CC_FOR_BUILD macro? I'm not sure how popular AX_PROG_CC_FOR_BUILD macro is and whether it's a canonical way of setting a compiler. Looking at the behaviour below I would say that macro has a problem of inferring defaults. > Shouldn't it be set by portage or the user killing cc? I don't think portage sets even CC environment variables for you unless you add it to make.conf explicitly. And yet even with CC not set 'cc' or 'gcc' does not get called for most ebuilds. They fall back to ${CHOST}-gcc (and other tools) via ./configure --host= magic. Why --build= should be different? In this case --build= configure's option ought to just have worked without any need for setting CC_FOR_BUILD. Maybe it's a sign of AX_PROG_CC_FOR_BUILD bug? I don't know for sure. If it's an intended behaviour of AX_PROG_CC_FOR_BUILD to use 'cc' / 'gcc' I would say we should override it with CC_FOR_BUILD=$(tc-getBUILD_CC) in ebuilds. If not then it should be fixed upstream to attempt --build= prefix for tools as well. Looking at today's definition http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_prog_cc_for_build.m4 it seems to attempt $build- / and $build_alias- prefixes. Maybe it was fixed since?
Added example to https://wiki.gentoo.org/wiki/Project:Toolchain/use_native_symlinks#CC_FOR_BUILD_.28AX_PROG_CC_FOR_BUILD.29_example and sent the question to autoconf-archive list.
