From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A5C241381F3 for ; Mon, 13 May 2013 06:57:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 86191E0A9A; Mon, 13 May 2013 06:57:36 +0000 (UTC) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 14C97E0A84 for ; Mon, 13 May 2013 06:57:34 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id j13so6171222wgh.16 for ; Sun, 12 May 2013 23:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=u24u3mpodaSFy+R0IsIBw4ueGC/ByQ+bQTyqE2WDcgg=; b=hbyeN8ikNNWdiBhBDSuh/XGCBeOIZnoUfdEWkssI3WYSVAssF5/0K+ZMBv/sevp0hR cscphlbeuQ67TJJXSwhZueapklfNB44KURxYlfRjMf05SA6Ht3I5melAg/dOU4XtOmEI 6YWzyy4DATCorRkuh99kJ5slyCu2yEWB5MBdazCvXa+yZ1sAF+BrzUtRzTjePLPF+Bjx SDvBZBJ3VP+2Ro+5Hlc89Iiq4rzd2sg5+5LDEnWUXRxGGCWRmVnuyFcYImrxe1VbBead RrnrT7/wD4Q8Nr0jv0lwy0K3Cg/TnJSVP2ttGMGE+azE40CgJtiPy2uLTfgrmJKfBBv0 JIxw== X-Received: by 10.180.88.231 with SMTP id bj7mr16353739wib.5.1368428253771; Sun, 12 May 2013 23:57:33 -0700 (PDT) Received: from [10.1.196.113] (dustpuppy.is.co.za. [196.14.169.11]) by mx.google.com with ESMTPSA id s1sm13508707wiz.2.2013.05.12.23.57.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 May 2013 23:57:32 -0700 (PDT) Message-ID: <51908ECA.4020101@gmail.com> Date: Mon, 13 May 2013 08:57:14 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130413 Thunderbird/17.0.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Gcc compiling, is this normal? References: <519006A0.2080807@gmail.com> <51900954.9050002@gmail.com> <51900F4D.2060907@gmail.com> In-Reply-To: <51900F4D.2060907@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 3b9cafcd-bb52-418b-8101-5e9e92f9cb26 X-Archives-Hash: 717be10867d34836feb974a218634975 On 12/05/2013 23:53, Dale wrote: > 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. I'm not sure what to make of this. portage lists the packages correctly and has the SLOTs correct, but emerge seems to be launched incorrectly. It's all very odd, and looks like bug-report material. To be useful you are going to need data. Could you quickpkg the current and previous versions of both SLOTs? That will make it easy to upgrade and downgrade packages, then run emerge world over and over to see what it does without it taking 40 minutes each time. -- Alan McKinnon alan.mckinnon@gmail.com