Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

[Anthony G. Basile]

On 12/30/17 12:18 PM, Andreas K. Huettel wrote:
> Am Samstag, 30. Dezember 2017, 13:22:52 CET schrieb Anthony G. Basile:
>> Hi everyone,
>>
>> We've been stuck on EAPI=4 with toolchain.eclass for a while.  This is
>> causing problems with subslotting libraries like mpfr, mpc, gmp and isl
>> that gcc depend on (see bug #642316).  I went through and made the
>> changes necessary to get the eclass up to EAPI=5 and compile tested
>> across the board (ie all dependent ebuilds) for amd64.  Everything looks
>> good, so please review and I'll commit if we're okay.
> 
> - confgcc+=( $(use_enable altivec) )
> + in_iuse altivec && confgcc+=( $(use_enable altivec) )
> 
> ^ Just as an example, such a construct may change the "default setting" when 
> no altivec useflag exists...
> 
> Imagine that upstream enables altivec by default (?). In earlier eapis, 
> use_enable with a non-existing useflag returned --disable-altivec (?). Now, 
> without the useflag, no setting is passed to configure, and it's enabled.
> 
> So, while this all works in principle, it may need careful per-flag review.
> 

Okay so I tested and found that there is no change in the default
settings due to the above construct (and there are a few).  The way I
did it was I built >=gcc-4.9.4 with and without the toolchain.eclass
patch and compared the config.log's (there's about 33 per version of
gcc).  There were no substantial differences.  If there would have been
a change in the default behavior, then lines like following would have
shown a difference.


  $ /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include/g++-v7
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls
--without-included-gettext --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 7.2.0
p1.1 --disable-esp --enable-libstdcxx-time --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-altivec
--disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp
--disable-libcilkrts --disable-libmpx --enable-vtable-verify
--enable-libvtv --enable-lto --without-isl --enable-libsanitizer
--disable-default-pie --enable-default-ssp


I didn't test earlier gcc versions because they're masked.  I tested
only on amd64 but I think that's oaky.  The only flag my tests don't
cover is the altivec flag (which is for ppc/ppc64), but it defaults off
on all gcc versions.

I think this puts your concern to rest.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

[Andreas K. Huettel]

Am Samstag, 30. Dezember 2017, 13:22:52 CET schrieb Anthony G. Basile:
> Hi everyone,
> 
> We've been stuck on EAPI=4 with toolchain.eclass for a while.  This is
> causing problems with subslotting libraries like mpfr, mpc, gmp and isl
> that gcc depend on (see bug #642316).  I went through and made the
> changes necessary to get the eclass up to EAPI=5 and compile tested
> across the board (ie all dependent ebuilds) for amd64.  Everything looks
> good, so please review and I'll commit if we're okay.

-   confgcc+=( $(use_enable altivec) )
+   in_iuse altivec && confgcc+=( $(use_enable altivec) )

^ Just as an example, such a construct may change the "default setting" when 
no altivec useflag exists...

Imagine that upstream enables altivec by default (?). In earlier eapis, 
use_enable with a non-existing useflag returned --disable-altivec (?). Now, 
without the useflag, no setting is passed to configure, and it's enabled.

So, while this all works in principle, it may need careful per-flag review.

-- 
Dr. Andreas K. Hüttel
tel. +49 151 241 67748 (mobile)
e-mail m...@akhuettel.de
http://www.akhuettel.de/

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

[Anthony G. Basile]

On 12/30/17 9:13 AM, Anthony G. Basile wrote:
> On 12/30/17 9:08 AM, Michael Orlitzky wrote:
>> On 12/30/2017 07:22 AM, Anthony G. Basile wrote:
>>> use_if_iuse !nopie && return 0
>>
>> Does this work? The "use" function supports negation (undocumented, but
>> it's in the PMS), but I don't think use_if_iuse does.
>>
> 
> Okay I'll read the code and test.  You're right that I just assumed it
> worked liked "use" wrt negation so the semantics need to be checked.
> 
> Thanks for looking this over carefully.
> 

It looks like it would not work as expected because eutils.eclass has

in_iuse() {
debug-print-function ${FUNCNAME} "${@}"
[[ ${#} -eq 1 ]] || die "Invalid args to ${FUNCNAME}()"

local flag=${1}
local liuse=( ${IUSE} )

has "${flag}" "${liuse[@]#[+-]}"
}

use_if_iuse() {
in_iuse $1 || return 1
use $1
}

So $1 in use_if_iuse binds to "!nopie" and then in in_iuse again to
"!nopie" which then messes up the has line, looking for a flag named
"!nopie" in IUSE which will always be true.

I'll change that line to

use_if_iuse nopie || return 0

Grepping the tree, I see only instances of

if ! use_if_iuse X ...

which is good.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

[Anthony G. Basile]

On 12/30/17 9:08 AM, Michael Orlitzky wrote:
> On 12/30/2017 07:22 AM, Anthony G. Basile wrote:
>> use_if_iuse !nopie && return 0
> 
> Does this work? The "use" function supports negation (undocumented, but
> it's in the PMS), but I don't think use_if_iuse does.
> 

Okay I'll read the code and test.  You're right that I just assumed it
worked liked "use" wrt negation so the semantics need to be checked.

Thanks for looking this over carefully.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

[Michael Orlitzky]

On 12/30/2017 07:22 AM, Anthony G. Basile wrote:
> use_if_iuse !nopie && return 0

Does this work? The "use" function supports negation (undocumented, but
it's in the PMS), but I don't think use_if_iuse does.

[gentoo-dev] Patches to update toolchain.eclass to EAPI=5

[Anthony G. Basile]

Hi everyone,

We've been stuck on EAPI=4 with toolchain.eclass for a while.  This is
causing problems with subslotting libraries like mpfr, mpc, gmp and isl
that gcc depend on (see bug #642316).  I went through and made the
changes necessary to get the eclass up to EAPI=5 and compile tested
across the board (ie all dependent ebuilds) for amd64.  Everything looks
good, so please review and I'll commit if we're okay.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA
From b4a707673b7a3e36959a071292807945b07fd018 Mon Sep 17 00:00:00 2001
From: "Anthony G. Basile" 
Date: Sat, 30 Dec 2017 06:56:29 -0500
Subject: [PATCH 1/2] toolchain.eclass: update to EAPI=5 standards

This eclass is inherited by ebuilds in sys-devel/{gcc,kgcc64,gcc-apple},
each which make use of different IUSE flags.   This causes problems with
`use X` construcitons when X is not in the IUSE flags.  At EAPI=4 this
simply emitted a warning, while at EAPI=5 this is an error.  We update
the eclass to make use of use_if_iuse and similar constructions where
necessary to bring the eclass into compliance with EAPI=5.

Signed-off-by: Anthony G. Basile 
---
 eclass/toolchain.eclass | 69 ++---
 1 file changed, 36 insertions(+), 33 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index a038303ec7f..bf6aa89e2fb 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -496,7 +496,7 @@ toolchain_src_prepare() {
do_gcc_PIE_patches
epatch_user
 
-   if ( tc_version_is_at_least 4.8.2 || use hardened ) && ! use vanilla ; 
then
+   if ( tc_version_is_at_least 4.8.2 || use_if_iuse hardened ) && ! use 
vanilla ; then
make_gcc_hard
fi
 
@@ -538,7 +538,7 @@ toolchain_src_prepare() {
fi
 
# >= gcc-4.3 doesn't bundle ecj.jar, so copy it
-   if tc_version_is_at_least 4.3 && use gcj ; then
+   if tc_version_is_at_least 4.3 && use_if_iuse gcj ; then
if tc_version_is_at_least 4.5 ; then
einfo "Copying ecj-4.5.jar"
cp -pPR "${DISTDIR}/ecj-4.5.jar" "${S}/ecj.jar" || die
@@ -648,20 +648,20 @@ make_gcc_hard() {
 
# Gcc >= 6.X we can use configurations options to turn pie/ssp on as 
default
if tc_version_is_at_least 6.0 ; then
-   if use pie ; then
+   if use_if_iuse pie ; then
einfo "Updating gcc to use automatic PIE building ..."
fi
-   if use ssp ; then
+   if use_if_iuse ssp ; then
einfo "Updating gcc to use automatic SSP building ..."
fi
-   if use hardened ; then
+   if use_if_iuse hardened ; then
# Will add some optimatizion as default.
gcc_hard_flags+=" -DEXTRA_OPTIONS"
# rebrand to make bug reports easier

BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
fi
else
-   if use hardened ; then
+   if use_if_iuse hardened ; then
# rebrand to make bug reports easier

BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
if hardened_gcc_works ; then
@@ -909,7 +909,7 @@ toolchain_src_configure() {
 
# Use the default ("release") checking because upstream usually neglects
# to test "disabled" so it has a history of breaking. #317217
-   if tc_version_is_at_least 3.4 ; then
+   if tc_version_is_at_least 3.4 && in_iuse debug ; then
# The "release" keyword is new to 4.0. #551636
local off=$(tc_version_is_at_least 4.0 && echo release || echo 
no)
confgcc+=( --enable-checking="${GCC_CHECKS_LIST:-$(usex debug 
yes ${off})}" )
@@ -922,7 +922,7 @@ toolchain_src_configure() {
)
 
# If we want hardened support with the newer piepatchset for >=gcc 4.4
-   if tc_version_is_at_least 4.4 && want_minispecs ; then
+   if tc_version_is_at_least 4.4 && want_minispecs && in_iuse hardened ; 
then
confgcc+=( $(use_enable hardened esp) )
fi
 
@@ -934,7 +934,7 @@ toolchain_src_configure() {
fi
 
# Support to disable pch when building libstdcxx
-   if tc_version_is_at_least 6.0 && ! use pch ; then
+   if tc_version_is_at_least 6.0 && ! use_if_iuse pch ; then
confgcc+=( --disable-libstdcxx-pch )
fi
 
@@ -1058,12 +1058,12 @@ toolchain_src_configure() {
gcc-multilib-configure
 
# ppc altivec support
-   confgcc+=( $(use_enable altivec) )
+   in_iuse altivec && confgcc+=( $(use_enable altivec) )
 
# gcc