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
