Re: [gentoo-user] Gcc compiling, is this normal?

[Alan McKinnon]

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.

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.mckinnon@×××××.com