| 1 |
On 12/30/17 12:18 PM, Andreas K. Huettel wrote: |
| 2 |
> Am Samstag, 30. Dezember 2017, 13:22:52 CET schrieb Anthony G. Basile: |
| 3 |
>> Hi everyone, |
| 4 |
>> |
| 5 |
>> We've been stuck on EAPI=4 with toolchain.eclass for a while. This is |
| 6 |
>> causing problems with subslotting libraries like mpfr, mpc, gmp and isl |
| 7 |
>> that gcc depend on (see bug #642316). I went through and made the |
| 8 |
>> changes necessary to get the eclass up to EAPI=5 and compile tested |
| 9 |
>> across the board (ie all dependent ebuilds) for amd64. Everything looks |
| 10 |
>> good, so please review and I'll commit if we're okay. |
| 11 |
> |
| 12 |
> - confgcc+=( $(use_enable altivec) ) |
| 13 |
> + in_iuse altivec && confgcc+=( $(use_enable altivec) ) |
| 14 |
> |
| 15 |
> ^ Just as an example, such a construct may change the "default setting" when |
| 16 |
> no altivec useflag exists... |
| 17 |
> |
| 18 |
> Imagine that upstream enables altivec by default (?). In earlier eapis, |
| 19 |
> use_enable with a non-existing useflag returned --disable-altivec (?). Now, |
| 20 |
> without the useflag, no setting is passed to configure, and it's enabled. |
| 21 |
> |
| 22 |
> So, while this all works in principle, it may need careful per-flag review. |
| 23 |
> |
| 24 |
|
| 25 |
Okay so I tested and found that there is no change in the default |
| 26 |
settings due to the above construct (and there are a few). The way I |
| 27 |
did it was I built >=gcc-4.9.4 with and without the toolchain.eclass |
| 28 |
patch and compared the config.log's (there's about 33 per version of |
| 29 |
gcc). There were no substantial differences. If there would have been |
| 30 |
a change in the default behavior, then lines like following would have |
| 31 |
shown a difference. |
| 32 |
|
| 33 |
|
| 34 |
$ /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/configure |
| 35 |
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr |
| 36 |
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.2.0 |
| 37 |
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include |
| 38 |
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0 |
| 39 |
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/man |
| 40 |
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/info |
| 41 |
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include/g++-v7 |
| 42 |
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/python |
| 43 |
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt |
| 44 |
--disable-werror --with-system-zlib --enable-nls |
| 45 |
--without-included-gettext --enable-checking=release |
| 46 |
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 7.2.0 |
| 47 |
p1.1 --disable-esp --enable-libstdcxx-time --enable-shared |
| 48 |
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu |
| 49 |
--enable-multilib --with-multilib-list=m32,m64 --disable-altivec |
| 50 |
--disable-fixed-point --enable-targets=all --disable-libgcj |
| 51 |
--enable-libgomp --disable-libmudflap --disable-libssp |
| 52 |
--disable-libcilkrts --disable-libmpx --enable-vtable-verify |
| 53 |
--enable-libvtv --enable-lto --without-isl --enable-libsanitizer |
| 54 |
--disable-default-pie --enable-default-ssp |
| 55 |
|
| 56 |
|
| 57 |
I didn't test earlier gcc versions because they're masked. I tested |
| 58 |
only on amd64 but I think that's oaky. The only flag my tests don't |
| 59 |
cover is the altivec flag (which is for ppc/ppc64), but it defaults off |
| 60 |
on all gcc versions. |
| 61 |
|
| 62 |
I think this puts your concern to rest. |
| 63 |
|
| 64 |
-- |
| 65 |
Anthony G. Basile, Ph.D. |
| 66 |
Gentoo Linux Developer [Hardened] |
| 67 |
E-Mail : blueness@g.o |
| 68 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 69 |
GnuPG ID : F52D4BBA |
Archives