1 |
On 12/05/2013 23:53, Dale wrote: |
2 |
> Alan McKinnon wrote: |
3 |
>> On 12/05/2013 23:16, Dale wrote: |
4 |
>>> Howdy, |
5 |
>>> |
6 |
>>> I been noticing something weird when I upgrade gcc. Is this normal? |
7 |
>>> |
8 |
>>> root@fireball / # genlop -c |
9 |
>>> |
10 |
>>> Currently merging 2 out of 5 |
11 |
>>> |
12 |
>>> * sys-devel/gcc-4.4.7 |
13 |
>>> |
14 |
>>> current merge time: 6 seconds. |
15 |
>>> ETA: 24 minutes and 27 seconds. |
16 |
>>> |
17 |
>>> Currently merging 3 out of 5 |
18 |
>>> |
19 |
>>> * net-misc/curl-7.30.0 |
20 |
>>> |
21 |
>>> current merge time: 7 seconds. |
22 |
>>> ETA: 18 minutes and 50 seconds. |
23 |
>>> |
24 |
>>> Currently merging 2 out of 5 |
25 |
>>> |
26 |
>>> * sys-devel/gcc-4.4.7 |
27 |
>>> |
28 |
>>> current merge time: 7 seconds. |
29 |
>>> ETA: 21 minutes and 14 seconds. |
30 |
>>> root@fireball / # |
31 |
>>> |
32 |
>>> |
33 |
>>> I'm not worried about curl. It just happened to be there. This is the |
34 |
>>> list of packages it is supposed to update: |
35 |
>>> |
36 |
>>> root@fireball / # emerge -uvaDN world |
37 |
>>> |
38 |
>>> These are the packages that would be merged, in order: |
39 |
>>> |
40 |
>>> Calculating dependencies... done! |
41 |
>>> [ebuild R ] sys-devel/gcc-4.5.4:4.5 USE="gtk mudflap (multilib) |
42 |
>>> nls nptl openmp (-altivec) -cxx -doc (-fixed-point) -fortran -gcj |
43 |
>>> (-hardened) (-libssp) -lto -multislot -nopie -nossp -objc -objc++ |
44 |
>>> -objc-gc {-test} -vanilla (-graphite%)" 0 kB |
45 |
>>> [ebuild R ] sys-devel/gcc-4.4.7:4.4 USE="gtk mudflap (multilib) |
46 |
>>> nls nptl openmp (-altivec) -cxx -doc (-fixed-point) -fortran -gcj |
47 |
>>> (-hardened) (-libssp) -multislot -nopie -nossp -objc -objc++ -objc-gc |
48 |
>>> {-test} -vanilla (-graphite%)" 0 kB |
49 |
>>> [ebuild U ] net-misc/curl-7.30.0 [7.29.0-r1] USE="ipv6 ssl threads |
50 |
>>> -adns -idn -kerberos -ldap -metalink -rtmp -ssh -static-libs {-test}" |
51 |
>>> CURL_SSL="openssl -axtls -cyassl -gnutls -nss -polarssl" 0 kB |
52 |
>>> [ebuild U ] app-misc/tmux-1.8 [1.6] USE="-vim-syntax" 0 kB |
53 |
>>> [ebuild U ~] kde-base/kdelibs-4.10.3-r2:4 [4.10.3:4] USE="3dnow alsa |
54 |
>>> bzip2 fam handbook jpeg2k lzma mmx nls opengl (policykit) |
55 |
>>> semantic-desktop spell sse sse2 ssl udev udisks upower zeroconf -acl |
56 |
>>> (-altivec) (-aqua) -debug -doc -kerberos -openexr {-test}" 0 kB |
57 |
>>> |
58 |
>>> Total: 5 packages (3 upgrades, 2 reinstalls), Size of downloads: 0 kB |
59 |
>>> |
60 |
>>> Would you like to merge these packages? [Yes/No] y |
61 |
>>> |
62 |
>>> I noticed this one or twice before. It is compiling the same compiler |
63 |
>>> version twice when it should be upgrading/recompiling two *different* |
64 |
>>> versions. I read before that gcc compiles three times or something but |
65 |
>>> the thing is, it can compile for HOURS and never finish. Usually I stop |
66 |
>>> it and restart emerge and it compiles as it should, one for each version |
67 |
>>> and finishes as it should time wise. I once started the upgrade and |
68 |
>>> went to take a nap. I woke up around 5 or 6 hours later to find gcc |
69 |
>>> compiling twice on the same version. Even libreoffice only takes a hour |
70 |
>>> or so. |
71 |
>>> |
72 |
>>> Anyone else see this before? Now to go stop this one and get it to |
73 |
>>> update right and not take all week. |
74 |
>> What have you got in world for gcc? |
75 |
> |
76 |
> |
77 |
> root@fireball / # cat /var/lib/portage/world | grep gcc |
78 |
> sys-devel/gcc:4.4 |
79 |
> sys-devel/gcc:4.5 |
80 |
> root@fireball / # |
81 |
> |
82 |
> I generally keep two versions. Got bit once. Long time ago but still, |
83 |
> no fun to fix. |
84 |
> |
85 |
> |
86 |
>> What's in make.conf? |
87 |
> |
88 |
> This is the USE line. I'm not sure if you want all the rest. Rest is |
89 |
> normal stuff, pretty much. lol |
90 |
> |
91 |
> USE="3dnow 3dnowext X a52 acpi alsa aml apng automount avahi \ |
92 |
> bash-completion bzip2 -cairo cddb cdr chroot cleartype clucene |
93 |
> corefonts \ |
94 |
> cups curl dbus declarative dri dvd dvdr embedded escreen esd \ |
95 |
> exif faac ffmpeg fontconfig -fortran gif gimp gkrellm gphoto2 \ |
96 |
> gtk hbci hddtemp iostats ipv6 java javascript jbig jpeg2k \ |
97 |
> justify kde kmod libwww logrotate loop-aes lvm lzma \ |
98 |
> mdnsresponder-compat melt mmx mmxext mng mp3 mplayer mysql nls |
99 |
> nsplugin \ |
100 |
> nvidia offensive ofx opengl openrc parport pdf pdfimport \ |
101 |
> policykit ppds ppp qt4 sasl seamonkey semantic-desktop sift smp \ |
102 |
> sse sse2 sse4a syslog tcl threads tiff tk truetype type1 udev \ |
103 |
> usb vcd webkit win32codecs wma wmf yahoo zeroconf -acl \ |
104 |
> -bluetooth -branding -doc -dts -eds -fftw -gcj -gnome -jabber \ |
105 |
> -jingle -ldap -musepack -openldap -oss -otr sqlite -sqlite3 -theora \ |
106 |
> -v41 -xulrunner -h -crypt -cxx" |
107 |
> |
108 |
> |
109 |
>> |
110 |
>> gcc's build system does cause gcc tro be built three times[1], but |
111 |
>> that's internal to gcc and has nothing to do with portage. There should |
112 |
>> still only be one emerge for a SLOT. If it's doing the same package |
113 |
>> twice, then the files in /var/tmp/portage are liable to get continually |
114 |
>> clobbered and who knows what will happen. |
115 |
>> |
116 |
>> |
117 |
>> [1] The logic goes something like this: it's a compiler, so the code it |
118 |
>> produces must be consistently identical for identical inputs. So, the |
119 |
>> current compiler builds gcc, giving version Y built by version X. That |
120 |
>> instance of gcc in turn builds a gcc, giving version Y built by version Y. |
121 |
>> |
122 |
>> Now you should have two copies of the same version of gcc, and they |
123 |
>> should be identical, plus the output code must also be identical. The |
124 |
>> gcc builds system checks for this by actually doing compiles and |
125 |
>> comparing the results. I've gotten a bit hazy on what specific bits |
126 |
>> actually do what, but that's the general concept. But all this |
127 |
>> rebuilding is internal and you only see it if you examine the console |
128 |
>> output scrolling by, it will never show up in any portage tools. |
129 |
>> |
130 |
> |
131 |
> I think your memory is right. That is what I remember too and I think |
132 |
> it was you explaining it but that was a while back. Here is the thing. |
133 |
> After my last post, I stopped the emerge. I emerged one version of gcc |
134 |
> and it emerged fine in the normal time of around 20 minutes. I then did |
135 |
> a emerge -uvaDN world and it compiled the other version and the rest as |
136 |
> it should. It seems when there is two versions of gcc to upgrade, |
137 |
> something gets weird. When I do one at a time, it works fine. I'm just |
138 |
> not sure why tho. Is it having two versions in world at the same time? |
139 |
> Surely not. I been doing that for a long time and this double thing |
140 |
> started a month or so ago. Thought it was a fluke at first. |
141 |
|
142 |
I'm not sure what to make of this. |
143 |
|
144 |
portage lists the packages correctly and has the SLOTs correct, but |
145 |
emerge seems to be launched incorrectly. It's all very odd, and looks |
146 |
like bug-report material. |
147 |
|
148 |
To be useful you are going to need data. Could you quickpkg the current |
149 |
and previous versions of both SLOTs? That will make it easy to upgrade |
150 |
and downgrade packages, then run emerge world over and over to see what |
151 |
it does without it taking 40 minutes each time. |
152 |
|
153 |
-- |
154 |
Alan McKinnon |
155 |
alan.mckinnon@×××××.com |