[gentoo-dev] [PATCH] media-libs/freetype: fix GCC usage during configure

[gentoo-dev] [PATCH] media-libs/freetype: fix GCC usage during configure

[Adrian Ratiu]

If $CC_BUILD is not set, configure defaults to GCC for some
of its tests causing clang builds to use a mixture of the
two compilers instead of using just clang consistently.

Here is an example before and after setting CC_BUILD (this
is actually from ChromiumOS where this was first detected).

before:

checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking for x86_64-pc-linux-gnu-gcc... (cached) x86_64-pc-linux-gnu-gcc
checking for x86_64-pc-linux-gnu-gcc... (cached) x86_64-pc-linux-gnu-gcc
checking for suffix of native executables...

after:

checking for x86_64-pc-linux-gnu-gcc... x86_64-cros-linux-gnu-clang
checking for x86_64-pc-linux-gnu-gcc... (cached) x86_64-cros-linux-gnu-clang
checking for x86_64-pc-linux-gnu-gcc... (cached) x86_64-cros-linux-gnu-clang
checking for suffix of native executables...

Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
---
 media-libs/freetype/freetype-2.11.0-r1.ebuild | 2 ++
 media-libs/freetype/freetype-2.11.0-r2.ebuild | 2 ++
 media-libs/freetype/freetype-2.11.1.ebuild    | 2 ++
 media-libs/freetype/freetype-9999.ebuild      | 2 ++
 4 files changed, 8 insertions(+)

diff --git a/media-libs/freetype/freetype-2.11.0-r1.ebuild b/media-libs/freetype/freetype-2.11.0-r1.ebuild
index b4e9e81a703..c9d88a7e108 100644
--- a/media-libs/freetype/freetype-2.11.0-r1.ebuild
+++ b/media-libs/freetype/freetype-2.11.0-r1.ebuild
@@ -203,6 +203,8 @@ multilib_src_configure() {
 		*) myeconfargs+=( ac_cv_prog_RC= ac_cv_prog_ac_ct_RC= ) ;;
 	esac
 
+	export CC_BUILD="$(tc-getBUILD_CC)"
+
 	ECONF_SOURCE="${S}" econf "${myeconfargs[@]}"
 }
 
diff --git a/media-libs/freetype/freetype-2.11.0-r2.ebuild b/media-libs/freetype/freetype-2.11.0-r2.ebuild
index 658322e92af..27f4cfde1ab 100644
--- a/media-libs/freetype/freetype-2.11.0-r2.ebuild
+++ b/media-libs/freetype/freetype-2.11.0-r2.ebuild
@@ -204,6 +204,8 @@ multilib_src_configure() {
 		*) myeconfargs+=( ac_cv_prog_RC= ac_cv_prog_ac_ct_RC= ) ;;
 	esac
 
+	export CC_BUILD="$(tc-getBUILD_CC)"
+
 	ECONF_SOURCE="${S}" econf "${myeconfargs[@]}"
 }
 
diff --git a/media-libs/freetype/freetype-2.11.1.ebuild b/media-libs/freetype/freetype-2.11.1.ebuild
index d0c71e729b9..7e891890302 100644
--- a/media-libs/freetype/freetype-2.11.1.ebuild
+++ b/media-libs/freetype/freetype-2.11.1.ebuild
@@ -195,6 +195,8 @@ multilib_src_configure() {
 		*) myeconfargs+=( ac_cv_prog_RC= ac_cv_prog_ac_ct_RC= ) ;;
 	esac
 
+	export CC_BUILD="$(tc-getBUILD_CC)"
+
 	ECONF_SOURCE="${S}" econf "${myeconfargs[@]}"
 }
 
diff --git a/media-libs/freetype/freetype-9999.ebuild b/media-libs/freetype/freetype-9999.ebuild
index d0c71e729b9..7e891890302 100644
--- a/media-libs/freetype/freetype-9999.ebuild
+++ b/media-libs/freetype/freetype-9999.ebuild
@@ -195,6 +195,8 @@ multilib_src_configure() {
 		*) myeconfargs+=( ac_cv_prog_RC= ac_cv_prog_ac_ct_RC= ) ;;
 	esac
 
+	export CC_BUILD="$(tc-getBUILD_CC)"
+
 	ECONF_SOURCE="${S}" econf "${myeconfargs[@]}"
 }
 
-- 
2.34.1

[gentoo-dev] Mailing list for ebuild patches? (Was: Re: [PATCH] media-libs/freetype: fix GCC usage during configure)

[Sam James]

[-- Attachment #1.1: Type: text/plain, Size: 1127 bytes --]



> On 7 Jan 2022, at 13:08, Adrian Ratiu <adrian.ratiu@collabora.com> wrote:
> 
> If $CC_BUILD is not set, configure defaults to GCC for some
> of its tests causing clang builds to use a mixture of the
> two compilers instead of using just clang consistently.
> [snip]

Thanks!

Looks like Polynomial-C applied this as https://github.com/gentoo/gentoo/commit/355c5b5715ffcf787c421d03209642d2823cf1f7 <https://github.com/gentoo/gentoo/commit/355c5b5715ffcf787c421d03209642d2823cf1f7>.

FWIW, normally we don't post individual package patches
to this ML, but it's a good question as to.. where they should go
if people want to use git send-email/a ML workflow.

Right now, sometimes people send them to gentoo-proxy-maint
(the list) which the proxy maintainers team that handles
most user contributions looks at, but I'll be honest and say
our workflow isn't really optimised for it given it's used
pretty infrequently.

Makes me wonder if we should rename the list
or have a separate one (gentoo-patches?).

(Or just use that list and make sure people CC
maintainers as you did here?)

Best,
sam

[-- Attachment #1.2: Type: text/html, Size: 2185 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] Mailing list for ebuild patches? (Was: Re: [PATCH] media-libs/freetype: fix GCC usage during configure)

[Anna Vyalkova]

On 2022-01-08 05:12, Sam James wrote:
> FWIW, normally we don't post individual package patches
> to this ML, but it's a good question as to.. where they should go
> if people want to use git send-email/a ML workflow.

Sending patches directly to maintainer(s) also works for git send-email
workflow.

> Makes me wonder if we should rename the list
> or have a separate one (gentoo-patches?).

I think gentoo-patches will only be useful if it's low-traffic,
otherwise devs may be unwilling to subscribe and pay attention to it.

Re: [gentoo-dev] Mailing list for ebuild patches? (Was: Re: [PATCH] media-libs/freetype: fix GCC usage during configure)

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 1089 bytes --]

On 8.1.2022 7.12, Sam James wrote:
> 
> FWIW, normally we don't post individual package patches
> to this ML, but it's a good question as to.. where they should go
> if people want to use git send-email/a ML workflow.
> 
> Right now, sometimes people send them to gentoo-proxy-maint
> (the list) which the proxy maintainers team that handles
> most user contributions looks at, but I'll be honest and say
> our workflow isn't really optimised for it given it's used
> pretty infrequently.
> 
> Makes me wonder if we should rename the list
> or have a separate one (gentoo-patches?).
> 
> (Or just use that list and make sure people CC
> maintainers as you did here?)
> 
> Best,
> sam

I don't think setting up a new mailing list purely for patches will
benefit much. It all comes down to who's gonna merge the contributions,
and Github/bugzilla are definitely easier in that regard. I suggest
opening a bug like normally, and then sending the .patch to the
maintainers directly via e-mail with bug #nr linked either in Subject or
git message body.

-- juippis

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]