On Sun, 12 May 2013 23:27:48 +0200
Alan McKinnon wrote:
> On 12/05/2013 23:16, Dale wrote:
> > Howdy,
> >
> > I been noticing something weird when I upgrade gcc. Is this normal?
> >
> > root@fireball / # genlop -c
> >
> > Currently merging 2 out of 5
> >
> > * sys-devel/gcc-4.4.7
> >
> > current merge time: 6 seconds.
> > ETA: 24 minutes and 27 seconds.
> >
> > Currently merging 3 out of 5
> >
> > * net-misc/curl-7.30.0
> >
> > current merge time: 7 seconds.
> > ETA: 18 minutes and 50 seconds.
> >
> > Currently merging 2 out of 5
> >
> > * sys-devel/gcc-4.4.7
> >
> > current merge time: 7 seconds.
> > ETA: 21 minutes and 14 seconds.
> > root@fireball / #
> >
> >
> > I'm not worried about curl. It just happened to be there. This is
> > the list of packages it is supposed to update:
> >
> > root@fireball / # emerge -uvaDN world
> >
> > These are the packages that would be merged, in order:
> >
> > Calculating dependencies... done!
> > [ebuild R ] sys-devel/gcc-4.5.4:4.5 USE="gtk mudflap
> > (multilib) nls nptl openmp (-altivec) -cxx -doc (-fixed-point)
> > -fortran -gcj (-hardened) (-libssp) -lto -multislot -nopie -nossp
> > -objc -objc++ -objc-gc {-test} -vanilla (-graphite%)" 0 kB
> > [ebuild R ] sys-devel/gcc-4.4.7:4.4 USE="gtk mudflap
> > (multilib) nls nptl openmp (-altivec) -cxx -doc (-fixed-point)
> > -fortran -gcj (-hardened) (-libssp) -multislot -nopie -nossp -objc
> > -objc++ -objc-gc {-test} -vanilla (-graphite%)" 0 kB
> > [ebuild U ] net-misc/curl-7.30.0 [7.29.0-r1] USE="ipv6 ssl
> > threads -adns -idn -kerberos -ldap -metalink -rtmp -ssh
> > -static-libs {-test}" CURL_SSL="openssl -axtls -cyassl -gnutls -nss
> > -polarssl" 0 kB [ebuild U ] app-misc/tmux-1.8 [1.6]
> > USE="-vim-syntax" 0 kB [ebuild U ~]
> > kde-base/kdelibs-4.10.3-r2:4 [4.10.3:4] USE="3dnow alsa bzip2 fam
> > handbook jpeg2k lzma mmx nls opengl (policykit) semantic-desktop
> > spell sse sse2 ssl udev udisks upower zeroconf -acl (-altivec)
> > (-aqua) -debug -doc -kerberos -openexr {-test}" 0 kB
> >
> > Total: 5 packages (3 upgrades, 2 reinstalls), Size of downloads: 0
> > kB
> >
> > Would you like to merge these packages? [Yes/No] y
> >
> > I noticed this one or twice before. It is compiling the same
> > compiler version twice when it should be upgrading/recompiling two
> > *different* versions. I read before that gcc compiles three times
> > or something but the thing is, it can compile for HOURS and never
> > finish. Usually I stop it and restart emerge and it compiles as it
> > should, one for each version and finishes as it should time wise.
> > I once started the upgrade and went to take a nap. I woke up
> > around 5 or 6 hours later to find gcc compiling twice on the same
> > version. Even libreoffice only takes a hour or so.
> >
> > Anyone else see this before? Now to go stop this one and get it to
> > update right and not take all week.
>
> What have you got in world for gcc?
> What's in make.conf?
>
> gcc's build system does cause gcc tro be built three times[1], but
> that's internal to gcc and has nothing to do with portage. There
> should still only be one emerge for a SLOT. If it's doing the same
> package twice, then the files in /var/tmp/portage are liable to get
> continually clobbered and who knows what will happen.
>
>
> [1] The logic goes something like this: it's a compiler, so the code
> it produces must be consistently identical for identical inputs. So,
> the current compiler builds gcc, giving version Y built by version X.
> That instance of gcc in turn builds a gcc, giving version Y built by
> version Y.
Haven't you left out the third compile?
Let me rephrase the 3 builds.
1) gcc-X builds gcc-Y giving gcc-Y1
2) gcc-Y1 builds gcc-Y giving gcc-Y2
3) gcc-Y2 builds gcc-Y giving gcc-Y3
gcc-Y1 and gcc-Y2 are likely to be different (since they were build by
gcc-X and gcc-Y which are likely to have optimizations).
gcc-Y2 and gcc-Y3 should be identical (since both were built by gcc-Y)
> Now you should have two copies of the same version of gcc, and they
> should be identical, plus the output code must also be identical. The
> gcc builds system checks for this by actually doing compiles and
> comparing the results. I've gotten a bit hazy on what specific bits
> actually do what, but that's the general concept. But all this
> rebuilding is internal and you only see it if you examine the console
> output scrolling by, it will never show up in any portage tools.
>
> --
> Alan McKinnon
> alan.mckin...@gmail.com
>
