Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 726186 - =x11-libs/gtk+-3.24.20 does not respect CC/CC_FOR_BUILD variable
Summary: =x11-libs/gtk+-3.24.20 does not respect CC/CC_FOR_BUILD variable
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks: tc-directly
  Show dependency tree
 
Reported: 2020-05-30 08:41 UTC by Sergei Trofimovich
Modified: 2020-07-08 11:06 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergei Trofimovich gentoo-dev 2020-05-30 08:41:20 UTC
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() {
Comment 1 Mart Raudsepp gentoo-dev 2020-05-30 08:49:54 UTC
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?
Comment 2 Sergei Trofimovich gentoo-dev 2020-05-30 09:52:49 UTC
(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?
Comment 3 Sergei Trofimovich gentoo-dev 2020-06-07 12:02:06 UTC
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.