1 |
On Sun, 12 May 2013 23:27:48 +0200 |
2 |
Alan McKinnon wrote: |
3 |
|
4 |
> On 12/05/2013 23:16, Dale wrote: |
5 |
> > Howdy, |
6 |
> > |
7 |
> > I been noticing something weird when I upgrade gcc. Is this normal? |
8 |
> > |
9 |
> > root@fireball / # genlop -c |
10 |
> > |
11 |
> > Currently merging 2 out of 5 |
12 |
> > |
13 |
> > * sys-devel/gcc-4.4.7 |
14 |
> > |
15 |
> > current merge time: 6 seconds. |
16 |
> > ETA: 24 minutes and 27 seconds. |
17 |
> > |
18 |
> > Currently merging 3 out of 5 |
19 |
> > |
20 |
> > * net-misc/curl-7.30.0 |
21 |
> > |
22 |
> > current merge time: 7 seconds. |
23 |
> > ETA: 18 minutes and 50 seconds. |
24 |
> > |
25 |
> > Currently merging 2 out of 5 |
26 |
> > |
27 |
> > * sys-devel/gcc-4.4.7 |
28 |
> > |
29 |
> > current merge time: 7 seconds. |
30 |
> > ETA: 21 minutes and 14 seconds. |
31 |
> > root@fireball / # |
32 |
> > |
33 |
> > |
34 |
> > I'm not worried about curl. It just happened to be there. This is |
35 |
> > the list of packages it is supposed to update: |
36 |
> > |
37 |
> > root@fireball / # emerge -uvaDN world |
38 |
> > |
39 |
> > These are the packages that would be merged, in order: |
40 |
> > |
41 |
> > Calculating dependencies... done! |
42 |
> > [ebuild R ] sys-devel/gcc-4.5.4:4.5 USE="gtk mudflap |
43 |
> > (multilib) nls nptl openmp (-altivec) -cxx -doc (-fixed-point) |
44 |
> > -fortran -gcj (-hardened) (-libssp) -lto -multislot -nopie -nossp |
45 |
> > -objc -objc++ -objc-gc {-test} -vanilla (-graphite%)" 0 kB |
46 |
> > [ebuild R ] sys-devel/gcc-4.4.7:4.4 USE="gtk mudflap |
47 |
> > (multilib) nls nptl openmp (-altivec) -cxx -doc (-fixed-point) |
48 |
> > -fortran -gcj (-hardened) (-libssp) -multislot -nopie -nossp -objc |
49 |
> > -objc++ -objc-gc {-test} -vanilla (-graphite%)" 0 kB |
50 |
> > [ebuild U ] net-misc/curl-7.30.0 [7.29.0-r1] USE="ipv6 ssl |
51 |
> > threads -adns -idn -kerberos -ldap -metalink -rtmp -ssh |
52 |
> > -static-libs {-test}" CURL_SSL="openssl -axtls -cyassl -gnutls -nss |
53 |
> > -polarssl" 0 kB [ebuild U ] app-misc/tmux-1.8 [1.6] |
54 |
> > USE="-vim-syntax" 0 kB [ebuild U ~] |
55 |
> > kde-base/kdelibs-4.10.3-r2:4 [4.10.3:4] USE="3dnow alsa bzip2 fam |
56 |
> > handbook jpeg2k lzma mmx nls opengl (policykit) semantic-desktop |
57 |
> > spell sse sse2 ssl udev udisks upower zeroconf -acl (-altivec) |
58 |
> > (-aqua) -debug -doc -kerberos -openexr {-test}" 0 kB |
59 |
> > |
60 |
> > Total: 5 packages (3 upgrades, 2 reinstalls), Size of downloads: 0 |
61 |
> > kB |
62 |
> > |
63 |
> > Would you like to merge these packages? [Yes/No] y |
64 |
> > |
65 |
> > I noticed this one or twice before. It is compiling the same |
66 |
> > compiler version twice when it should be upgrading/recompiling two |
67 |
> > *different* versions. I read before that gcc compiles three times |
68 |
> > or something but the thing is, it can compile for HOURS and never |
69 |
> > finish. Usually I stop it and restart emerge and it compiles as it |
70 |
> > should, one for each version and finishes as it should time wise. |
71 |
> > I once started the upgrade and went to take a nap. I woke up |
72 |
> > around 5 or 6 hours later to find gcc compiling twice on the same |
73 |
> > version. Even libreoffice only takes a hour or so. |
74 |
> > |
75 |
> > Anyone else see this before? Now to go stop this one and get it to |
76 |
> > update right and not take all week. |
77 |
> |
78 |
> What have you got in world for gcc? |
79 |
> What's in make.conf? |
80 |
> |
81 |
> gcc's build system does cause gcc tro be built three times[1], but |
82 |
> that's internal to gcc and has nothing to do with portage. There |
83 |
> should still only be one emerge for a SLOT. If it's doing the same |
84 |
> package twice, then the files in /var/tmp/portage are liable to get |
85 |
> continually clobbered and who knows what will happen. |
86 |
> |
87 |
> |
88 |
> [1] The logic goes something like this: it's a compiler, so the code |
89 |
> it produces must be consistently identical for identical inputs. So, |
90 |
> the current compiler builds gcc, giving version Y built by version X. |
91 |
> That instance of gcc in turn builds a gcc, giving version Y built by |
92 |
> version Y. |
93 |
|
94 |
Haven't you left out the third compile? |
95 |
|
96 |
Let me rephrase the 3 builds. |
97 |
|
98 |
1) gcc-X builds gcc-Y giving gcc-Y1 |
99 |
2) gcc-Y1 builds gcc-Y giving gcc-Y2 |
100 |
3) gcc-Y2 builds gcc-Y giving gcc-Y3 |
101 |
|
102 |
gcc-Y1 and gcc-Y2 are likely to be different (since they were build by |
103 |
gcc-X and gcc-Y which are likely to have optimizations). |
104 |
|
105 |
gcc-Y2 and gcc-Y3 should be identical (since both were built by gcc-Y) |
106 |
|
107 |
> Now you should have two copies of the same version of gcc, and they |
108 |
> should be identical, plus the output code must also be identical. The |
109 |
> gcc builds system checks for this by actually doing compiles and |
110 |
> comparing the results. I've gotten a bit hazy on what specific bits |
111 |
> actually do what, but that's the general concept. But all this |
112 |
> rebuilding is internal and you only see it if you examine the console |
113 |
> output scrolling by, it will never show up in any portage tools. |
114 |
> |
115 |
> -- |
116 |
> Alan McKinnon |
117 |
> alan.mckinnon@×××××.com |
118 |
> |