Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Gcc compiling, is this normal?
Date: Mon, 13 May 2013 06:57:43
Message-Id: 51908ECA.4020101@gmail.com
In Reply to: Re: [gentoo-user] Gcc compiling, is this normal? by Dale
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

Replies

Subject Author
Re: [gentoo-user] Gcc compiling, is this normal? Dale <rdalek1967@×××××.com>