From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Gcc compiling, is this normal?
Date: Mon, 13 May 2013 08:57:14 +0200 [thread overview]
Message-ID: <51908ECA.4020101@gmail.com> (raw)
In-Reply-To: <51900F4D.2060907@gmail.com>
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
next prev parent reply other threads:[~2013-05-13 6:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-12 21:16 [gentoo-user] Gcc compiling, is this normal? Dale
2013-05-12 21:27 ` Alan McKinnon
2013-05-12 21:37 ` David Relson
2013-05-13 6:45 ` Alan McKinnon
2013-05-12 21:53 ` Dale
2013-05-13 6:57 ` Alan McKinnon [this message]
2013-05-13 8:56 ` Dale
2013-05-13 10:04 ` J. Roeleveld
2013-05-13 10:30 ` Dale
2013-05-13 11:16 ` Dale
2013-05-13 11:21 ` J. Roeleveld
2013-05-13 11:31 ` Marc Joliet
2013-05-13 11:47 ` Dale
2013-05-13 11:43 ` Dale
2013-05-13 13:05 ` J. Roeleveld
2013-05-13 14:42 ` Peter Humphrey
2013-05-13 17:11 ` Dale
2013-05-13 22:08 ` Neil Bothwick
2013-05-13 22:22 ` Dale
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51908ECA.4020101@gmail.com \
--to=alan.mckinnon@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox