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?
root@fireball / # cat /var/lib/portage/world | grep gcc
sys-devel/gcc:4.4
sys-devel/gcc:4.5
root@fireball / #
I generally keep two versions. Got bit once. Long time ago but still,
no fun to fix.
> What's in make.conf?
This is the USE line. I'm not sure if you want all the rest. Rest is
normal stuff, pretty much. lol
USE="3dnow 3dnowext X a52 acpi alsa aml apng automount avahi \
bash-completion bzip2 -cairo cddb cdr chroot cleartype clucene
corefonts \
cups curl dbus declarative dri dvd dvdr embedded escreen esd \
exif faac ffmpeg fontconfig -fortran gif gimp gkrellm gphoto2 \
gtk hbci hddtemp iostats ipv6 java javascript jbig jpeg2k \
justify kde kmod libwww logrotate loop-aes lvm lzma \
mdnsresponder-compat melt mmx mmxext mng mp3 mplayer mysql nls
nsplugin \
nvidia offensive ofx opengl openrc parport pdf pdfimport \
policykit ppds ppp qt4 sasl seamonkey semantic-desktop sift smp \
sse sse2 sse4a syslog tcl threads tiff tk truetype type1 udev \
usb vcd webkit win32codecs wma wmf yahoo zeroconf -acl \
-bluetooth -branding -doc -dts -eds -fftw -gcj -gnome -jabber \
-jingle -ldap -musepack -openldap -oss -otr sqlite -sqlite3 -theora \
-v41 -xulrunner -h -crypt -cxx"
>
> 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.
>
I think your memory is right. That is what I remember too and I think
it was you explaining it but that was a while back. Here is the thing.
After my last post, I stopped the emerge. I emerged one version of gcc
and it emerged fine in the normal time of around 20 minutes. I then did
a emerge -uvaDN world and it compiled the other version and the rest as
it should. It seems when there is two versions of gcc to upgrade,
something gets weird. When I do one at a time, it works fine. I'm just
not sure why tho. Is it having two versions in world at the same time?
Surely not. I been doing that for a long time and this double thing
started a month or so ago. Thought it was a fluke at first.
Weird huh?
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
