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 |