Re: [gentoo-user] Gcc compiling, is this normal?
On 12/05/2013 23:37, David Relson wrote: [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) Yeah, I think you're right. Thanks for that. Like I said, I'm fuzzy on the details after all these years. My intention was not to be completely accurate and correct, it was more to get the general idea across to Dale -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Gcc compiling, is this normal?
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
Re: [gentoo-user] Gcc compiling, is this normal?
Alan McKinnon wrote:
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.
Well, here is this:
[-P-] [ ] sys-apps/portage-2.1.11.63:0
[-P-] [ ] sys-apps/portage-2.2.0_alpha173:0
[IP-] [ ] sys-apps/portage-2.2.0_alpha174:0
This is the portage update info. I use genlop -t to do this. I know
there is a better way but can't remember the command. lol I think it
was one of the q thingys.
Fri Apr 5 12:49:29 2013 sys-apps/portage-2.2.0_alpha171
merge time: 27 seconds.
Sat Apr 6 11:00:10 2013 sys-apps/portage-2.2.0_alpha171
merge time: 26 seconds.
Mon Apr 15 08:33:49 2013 sys-apps/portage-2.2.0_alpha173
merge time: 31 seconds.
Mon May 6 22:36:15 2013 sys-apps/portage-2.2.0_alpha174
merge time: 30 seconds.
Based on that, I would say it started about the time *173 hit. I can't
go back to the *171 since it is no longer in the tree.
I'm not sure I know enough about debugging to help much but it sure is
weird. Should have known something weird like this would hit me. :/
I'm sort of pretty active on this thing right now since I do some
volunteer mod work on a site. I'd rather not get myself to a spot where
my rig aini't working. I'm not even doing upgrades like I used to.
Well, not as often anyway. I just have to plan stuff to make sure I'm
up and running.
I checked for roach reports and didn't see this reported anywhere. I
wonder if a USE flag is triggering this? This is interesting:
root@fireball / # emerge -pv =sys-devel/gcc-4.4.7 =sys-devel/gcc-4.5.4
=sys-devel/gcc-4.6.3
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R] sys-devel/gcc-4.6.3:4.6 USE=gtk mudflap (multilib)
nls nptl openmp (-altivec) -cxx* -doc (-fixed-point) -fortran* -gcj
-graphite (-hardened) (-libssp) -multislot -nopie -nossp -objc -objc++
-objc-gc {-test} -vanilla 24 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 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 0 kB
Total: 3 packages (3 reinstalls), Size of downloads: 24 kB
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
sys-devel/gcc:4.6
(sys-devel/gcc-4.6.3::gentoo, ebuild scheduled for merge) pulled in by
(no parents that aren't satisfied by other packages in this slot)
(sys-devel/gcc-4.6.3::gentoo, installed) pulled in by
sys-devel/gcc[fortran,openmp?] required by
(virtual/fortran-0::gentoo, installed)
=sys-devel/gcc-4.2[cxx] required by
(sci-geosciences/googleearth-6.2.2.6613::gentoo, installed)
!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.
root@fireball / #
I may need to make sense of this now. May not be the problem but
still. I don't have anything related to gcc in package.use either. I'm
not sure about the USE flag being changed on two but not the other.
When I logoff as mod, I'm going to try to recompile that older version.
Thoughts? Could that be the cause?
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
Re: [gentoo-user] Gcc compiling, is this normal?
Dale rdalek1...@gmail.com wrote:
Alan McKinnon wrote:
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.
Well, here is this:
[-P-] [ ] sys-apps/portage-2.1.11.63:0
[-P-] [ ] sys-apps/portage-2.2.0_alpha173:0
[IP-] [ ] sys-apps/portage-2.2.0_alpha174:0
This is the portage update info. I use genlop -t to do this. I know
there is a better way but can't remember the command. lol I think it
was one of the q thingys.
Fri Apr 5 12:49:29 2013 sys-apps/portage-2.2.0_alpha171
merge time: 27 seconds.
Sat Apr 6 11:00:10 2013 sys-apps/portage-2.2.0_alpha171
merge time: 26 seconds.
Mon Apr 15 08:33:49 2013 sys-apps/portage-2.2.0_alpha173
merge time: 31 seconds.
Mon May 6 22:36:15 2013 sys-apps/portage-2.2.0_alpha174
merge time: 30 seconds.
Based on that, I would say it started about the time *173 hit. I can't
go back to the *171 since it is no longer in the tree.
I'm not sure I know enough about debugging to help much but it sure is
weird. Should have known something weird like this would hit me. :/
I'm sort of pretty active on this thing right now since I do some
volunteer mod work on a site. I'd rather not get myself to a spot
where
my rig aini't working. I'm not even doing upgrades like I used to.
Well, not as often anyway. I just have to plan stuff to make sure I'm
up and running.
I checked for roach reports and didn't see this reported anywhere. I
wonder if a USE flag is triggering this? This is interesting:
root@fireball / # emerge -pv =sys-devel/gcc-4.4.7 =sys-devel/gcc-4.5.4
=sys-devel/gcc-4.6.3
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R] sys-devel/gcc-4.6.3:4.6 USE=gtk mudflap (multilib)
nls nptl openmp (-altivec) -cxx* -doc (-fixed-point) -fortran* -gcj
-graphite (-hardened) (-libssp) -multislot -nopie -nossp -objc -objc++
-objc-gc {-test} -vanilla 24 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 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 0 kB
Total: 3 packages (3 reinstalls), Size of downloads: 24 kB
!!! Multiple package instances within a single package slot have been
pulled
!!! into the dependency graph, resulting in a slot conflict:
sys-devel/gcc:4.6
(sys-devel/gcc-4.6.3::gentoo, ebuild scheduled for merge) pulled in by
(no parents that aren't satisfied by other packages in this slot)
(sys-devel/gcc-4.6.3::gentoo, installed) pulled in by
sys-devel/gcc[fortran,openmp?] required by
(virtual/fortran-0::gentoo, installed)
=sys-devel/gcc-4.2[cxx] required by
(sci-geosciences/googleearth-6.2.2.6613::gentoo, installed)
!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.
root@fireball / #
I may need to make sense of this now. May not be the problem but
still. I don't have anything related to gcc in package.use either.
I'm
not sure about the USE flag being changed on two but not the other.
When I logoff as mod, I'm going to try to recompile that older version.
Thoughts? Could that be the cause?
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood
or how you interpreted my words!
Dale.
My thoughts: enable the 'multislot' useflag for gcc.
Portage is seeing all three as being in the same slot...
--
Joost
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Gcc compiling, is this normal?
J. Roeleveld wrote:
Dale. My thoughts: enable the 'multislot' useflag for gcc. Portage is
seeing all three as being in the same slot... -- Joost
Now that started something there. Nifty.
root@fireball / # emerge -uvaDN world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] app-misc/tmux-1.8 [1.6] USE=-vim-syntax 0 kB
[ebuild R] sys-devel/gcc-4.6.3:4.6 USE=cxx fortran gtk mudflap
(multilib) multislot* nls nptl openmp (-altivec) -doc (-fixed-point)
-gcj -graphite (-hardened) (-libssp) -nopie -nossp -objc -objc++
-objc-gc {-test} -vanilla 24 kB
[ebuild R] sys-devel/gcc-4.5.4:4.5 USE=cxx* fortran* gtk mudflap
(multilib) multislot* nls nptl openmp (-altivec) -doc (-fixed-point)
-gcj (-hardened) (-libssp) -lto -nopie -nossp -objc -objc++ -objc-gc
{-test} -vanilla 0 kB
[ebuild R] sys-devel/gcc-4.4.7:4.4 USE=cxx* fortran* gtk mudflap
(multilib) multislot* nls nptl openmp (-altivec) -doc (-fixed-point)
-gcj (-hardened) (-libssp) -nopie -nossp -objc -objc++ -objc-gc {-test}
-vanilla (-graphite%) 0 kB
Total: 4 packages (1 upgrade, 3 reinstalls), Size of downloads: 24 kB
Would you like to merge these packages? [Yes/No]
To get to that point, I had to add the USE flag you mentioned and then I
got more understandable errors. I had to make the following change to
my package.use file:
sys-devel/gcc multislot cxx fortran
media-libs/flac cxx
The multislot addition then told me to add cxx and fortran. Then that
lead to the one for flac. I'm going to add that to make.conf and just
see what changes. I TRY to keep my USE flags in make.conf when I can.
Since this is plan text and I can't type it bigger like if it was html.
THANK YOU
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
Re: [gentoo-user] Gcc compiling, is this normal?
Dale wrote:
J. Roeleveld wrote:
Dale. My thoughts: enable the 'multislot' useflag for gcc. Portage is
seeing all three as being in the same slot... -- Joost
Now that started something there. Nifty.
root@fireball / # emerge -uvaDN world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] app-misc/tmux-1.8 [1.6] USE=-vim-syntax 0 kB
[ebuild R] sys-devel/gcc-4.6.3:4.6 USE=cxx fortran gtk mudflap
(multilib) multislot* nls nptl openmp (-altivec) -doc (-fixed-point)
-gcj -graphite (-hardened) (-libssp) -nopie -nossp -objc -objc++
-objc-gc {-test} -vanilla 24 kB
[ebuild R] sys-devel/gcc-4.5.4:4.5 USE=cxx* fortran* gtk mudflap
(multilib) multislot* nls nptl openmp (-altivec) -doc (-fixed-point)
-gcj (-hardened) (-libssp) -lto -nopie -nossp -objc -objc++ -objc-gc
{-test} -vanilla 0 kB
[ebuild R] sys-devel/gcc-4.4.7:4.4 USE=cxx* fortran* gtk mudflap
(multilib) multislot* nls nptl openmp (-altivec) -doc (-fixed-point)
-gcj (-hardened) (-libssp) -nopie -nossp -objc -objc++ -objc-gc {-test}
-vanilla (-graphite%) 0 kB
Total: 4 packages (1 upgrade, 3 reinstalls), Size of downloads: 24 kB
Would you like to merge these packages? [Yes/No]
To get to that point, I had to add the USE flag you mentioned and then I
got more understandable errors. I had to make the following change to
my package.use file:
sys-devel/gcc multislot cxx fortran
media-libs/flac cxx
The multislot addition then told me to add cxx and fortran. Then that
lead to the one for flac. I'm going to add that to make.conf and just
see what changes. I TRY to keep my USE flags in make.conf when I can.
Since this is plan text and I can't type it bigger like if it was html.
THANK YOU
Dale
:-) :-)
Well, after waiting for it to finish, I get this now:
root@fireball / # genlop -c
Currently merging 4 out of 4
* sys-devel/gcc-4.4.7
current merge time: 6 minutes and 57 seconds.
ETA: 17 minutes and 2 seconds.
Currently merging 4 out of 4
* sys-devel/gcc-4.4.7
current merge time: 6 minutes and 58 seconds.
ETA: 17 minutes and 1 second.
root@fireball / #
So there it is compiling the same package version twice, again. Going
to kill it since it will sit there and compile for hours if I don't. I
also found out I am not the only one having issues doing a ctrl c to
stop emerge too. They need some Raid on that problem.
Open to new ideas.
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
Re: [gentoo-user] Gcc compiling, is this normal?
On Mon, May 13, 2013 13:16, Dale wrote:
Dale wrote:
J. Roeleveld wrote:
Dale. My thoughts: enable the 'multislot' useflag for gcc. Portage is
seeing all three as being in the same slot... -- Joost
Now that started something there. Nifty.
root@fireball / # emerge -uvaDN world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] app-misc/tmux-1.8 [1.6] USE=-vim-syntax 0 kB
[ebuild R] sys-devel/gcc-4.6.3:4.6 USE=cxx fortran gtk mudflap
(multilib) multislot* nls nptl openmp (-altivec) -doc (-fixed-point)
-gcj -graphite (-hardened) (-libssp) -nopie -nossp -objc -objc++
-objc-gc {-test} -vanilla 24 kB
[ebuild R] sys-devel/gcc-4.5.4:4.5 USE=cxx* fortran* gtk mudflap
(multilib) multislot* nls nptl openmp (-altivec) -doc (-fixed-point)
-gcj (-hardened) (-libssp) -lto -nopie -nossp -objc -objc++ -objc-gc
{-test} -vanilla 0 kB
[ebuild R] sys-devel/gcc-4.4.7:4.4 USE=cxx* fortran* gtk mudflap
(multilib) multislot* nls nptl openmp (-altivec) -doc (-fixed-point)
-gcj (-hardened) (-libssp) -nopie -nossp -objc -objc++ -objc-gc {-test}
-vanilla (-graphite%) 0 kB
Total: 4 packages (1 upgrade, 3 reinstalls), Size of downloads: 24 kB
Would you like to merge these packages? [Yes/No]
To get to that point, I had to add the USE flag you mentioned and then I
got more understandable errors. I had to make the following change to
my package.use file:
sys-devel/gcc multislot cxx fortran
media-libs/flac cxx
The multislot addition then told me to add cxx and fortran. Then that
lead to the one for flac. I'm going to add that to make.conf and just
see what changes. I TRY to keep my USE flags in make.conf when I can.
I try to keep the USE-flags out of make.conf as much as possible.
Some packages have multislot where I don't necessarily want it enabled.
Since this is plan text and I can't type it bigger like if it was html.
THANK YOU
Dale
:-) :-)
Well, after waiting for it to finish, I get this now:
root@fireball / # genlop -c
Currently merging 4 out of 4
* sys-devel/gcc-4.4.7
current merge time: 6 minutes and 57 seconds.
ETA: 17 minutes and 2 seconds.
Currently merging 4 out of 4
* sys-devel/gcc-4.4.7
current merge time: 6 minutes and 58 seconds.
ETA: 17 minutes and 1 second.
root@fireball / #
So there it is compiling the same package version twice, again. Going
to kill it since it will sit there and compile for hours if I don't. I
also found out I am not the only one having issues doing a ctrl c to
stop emerge too. They need some Raid on that problem.
Open to new ideas.
Just a quick question, are you certain it is doing both simultaneously?
It could also be a bug in genlop?
I always generate the binary packages, which means I don't actually need
to keep older GCC-versions. I can always unpack the package using tar :)
--
Joost
Re: [gentoo-user] Gcc compiling, is this normal?
Am Mon, 13 May 2013 13:21:37 +0200 schrieb J. Roeleveld jo...@antarean.org: Just a quick question, are you certain it is doing both simultaneously? It could also be a bug in genlop? I was thinking that, too. Dale, I would suggest you check the contents of /var/tmp/portage/sys-devel/ (maybe clean it up first before running emerge again so that previously failed compiles don't confuse us) and see what versions of gcc are listed there. Of course, there is still a bug somewhere, since as you say the compiles go on indefinitely. This should just help limit the scope of whatever is happening. HTH -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
Re: [gentoo-user] Gcc compiling, is this normal?
J. Roeleveld wrote: I try to keep the USE-flags out of make.conf as much as possible. Some packages have multislot where I don't necessarily want it enabled. It turned into a USE flag nightmare so I used package.use. Sometimes it just don't work out since a few packages gets into a world class wrestling match. I usually try but don't sweat it. Well, after waiting for it to finish, I get this now: root@fireball / # genlop -c Currently merging 4 out of 4 * sys-devel/gcc-4.4.7 current merge time: 6 minutes and 57 seconds. ETA: 17 minutes and 2 seconds. Currently merging 4 out of 4 * sys-devel/gcc-4.4.7 current merge time: 6 minutes and 58 seconds. ETA: 17 minutes and 1 second. root@fireball / # So there it is compiling the same package version twice, again. Going to kill it since it will sit there and compile for hours if I don't. I also found out I am not the only one having issues doing a ctrl c to stop emerge too. They need some Raid on that problem. Open to new ideas. Just a quick question, are you certain it is doing both simultaneously? It could also be a bug in genlop? I always generate the binary packages, which means I don't actually need to keep older GCC-versions. I can always unpack the package using tar :) -- Joost I have it set to save a tarball here but I'd have to look up how to rescue myself if I did screw up. To answer your question, I decided to just let the stupid thing sit there and compile. After a while, I got this: root@fireball / # genlop -c Currently merging 4 out of 4 * sys-devel/gcc-4.4.7 current merge time: 25 minutes and 17 seconds. ETA: any time now. root@fireball / # So, one of the compiles finished. That is a improvement at least. I just checked again and it is finished with them all and I got this for the end of emerge: Total: 4 packages (1 upgrade, 3 reinstalls), Size of downloads: 24 kB Would you like to merge these packages? [Yes/No] y Verifying ebuild manifests Emerging (1 of 4) app-misc/tmux-1.8 Emerging (2 of 4) sys-devel/gcc-4.6.3 Installing (1 of 4) app-misc/tmux-1.8 Installing (2 of 4) sys-devel/gcc-4.6.3 Emerging (3 of 4) sys-devel/gcc-4.5.4 Emerging (4 of 4) sys-devel/gcc-4.4.7 Installing (4 of 4) sys-devel/gcc-4.4.7 Installing (3 of 4) sys-devel/gcc-4.5.4 Jobs: 4 of 4 complete Load avg: 7.6, 13.4, 14.7 Auto-cleaning packages... No outdated packages were found on your system. * Regenerating GNU info directory index... * Processed 7 info files. * After world updates, it is important to remove obsolete packages with * emerge --depclean. Refer to `man emerge` for more information. root@fireball / # I'm going to say this tho, it did not have time to compile the last gcc even tho I'm sure it did. Your mention of a genlop error may be right. I bet genlop is reporting the wrong version on one of them somehow. To add this in case I didn't mention it. One time before, gcc compiled for like 5 or 6 hours while I took a nap. I can compile LOo several times in that time frame. Gcc never takes more than 30 minutes or so, usually around 20 or so. I have a 4 core CPU running at I think 3.2Ghz and 16Gbs of ram with portages work directory on tmpfs. This is weird. May look into a genlop change, up to a unstable one or back to a older version. See if that helps. Got to figure out how to force a upgrade tho. ;-) Thanks. At least I seem to have a clean upgrade now. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Gcc compiling, is this normal?
Marc Joliet wrote: Am Mon, 13 May 2013 13:21:37 +0200 schrieb J. Roeleveld jo...@antarean.org: Just a quick question, are you certain it is doing both simultaneously? It could also be a bug in genlop? I was thinking that, too. Dale, I would suggest you check the contents of /var/tmp/portage/sys-devel/ (maybe clean it up first before running emerge again so that previously failed compiles don't confuse us) and see what versions of gcc are listed there. Of course, there is still a bug somewhere, since as you say the compiles go on indefinitely. This should just help limit the scope of whatever is happening. HTH It could very well be genlop. I just sent a reply to Joost. I checked portages work directory, just a old failed memtest thing from earlier. Nothing there about gcc at all. I have that on tmpfs so it cleans itself when I reboot. I rebooted yesterday I think. Spring blow of the dust. Makes me wonder about genlop but at least it finished this time. Maybe USE flag caused the infinite compile and genlop just needs some Raid. lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Gcc compiling, is this normal?
On Mon, May 13, 2013 13:43, Dale wrote: J. Roeleveld wrote: I try to keep the USE-flags out of make.conf as much as possible. Some packages have multislot where I don't necessarily want it enabled. It turned into a USE flag nightmare so I used package.use. Sometimes it just don't work out since a few packages gets into a world class wrestling match. I usually try but don't sweat it. My make.conf USE-variable is really small, it's all in package.use/... :) Well, after waiting for it to finish, I get this now: root@fireball / # genlop -c Currently merging 4 out of 4 * sys-devel/gcc-4.4.7 current merge time: 6 minutes and 57 seconds. ETA: 17 minutes and 2 seconds. Currently merging 4 out of 4 * sys-devel/gcc-4.4.7 current merge time: 6 minutes and 58 seconds. ETA: 17 minutes and 1 second. root@fireball / # So there it is compiling the same package version twice, again. Going to kill it since it will sit there and compile for hours if I don't. I also found out I am not the only one having issues doing a ctrl c to stop emerge too. They need some Raid on that problem. Open to new ideas. Just a quick question, are you certain it is doing both simultaneously? It could also be a bug in genlop? I always generate the binary packages, which means I don't actually need to keep older GCC-versions. I can always unpack the package using tar :) -- Joost I have it set to save a tarball here but I'd have to look up how to rescue myself if I did screw up. To rescue yourself using a binpackage: # cd / # tar -xvjpf ...path-to-binpackage-including-package... After that, I would suggest a emerge -vek world :) To answer your question, I decided to just let the stupid thing sit there and compile. After a while, I got this: root@fireball / # genlop -c Currently merging 4 out of 4 * sys-devel/gcc-4.4.7 current merge time: 25 minutes and 17 seconds. ETA: any time now. root@fireball / # So, one of the compiles finished. That is a improvement at least. I just checked again and it is finished with them all and I got this for the end of emerge: Total: 4 packages (1 upgrade, 3 reinstalls), Size of downloads: 24 kB Would you like to merge these packages? [Yes/No] y SNIPPED I'm going to say this tho, it did not have time to compile the last gcc even tho I'm sure it did. Your mention of a genlop error may be right. I bet genlop is reporting the wrong version on one of them somehow. I wonder if genlop is noticing there are 2 GCC-compiles running, but picks the most current version for both, rather then the correct version for each emerge? To add this in case I didn't mention it. One time before, gcc compiled for like 5 or 6 hours while I took a nap. I can compile LOo several times in that time frame. Gcc never takes more than 30 minutes or so, usually around 20 or so. That depends on the USE-flags, I think. GCC on my old system always took a while, new systems (with also new versions) seem to be a lot faster. Thing is, I tend to build packages for all the machines in a single VM and then install those when I have a current set. That VM tends to be started and then I just leave it till I come back from work the next day. I have a 4 core CPU running at I think 3.2Ghz and 16Gbs of ram with portages work directory on tmpfs. This is weird. May look into a genlop change, up to a unstable one or back to a older version. See if that helps. Got to figure out how to force a upgrade tho. ;-) Thanks. At least I seem to have a clean upgrade now. You might already had :) -- Joost
Re: [gentoo-user] Gcc compiling, is this normal?
On Monday 13 May 2013 14:05:24 J. Roeleveld wrote: I wonder if genlop is noticing there are 2 GCC-compiles running, but picks the most current version for both, rather then the correct version for each emerge? That rings a bell. I think I spotted something of the sort several months ago. Don't remember which package though. Is there an easy way to find what packages I have several versions of? -- Peter
Re: [gentoo-user] Gcc compiling, is this normal?
J. Roeleveld wrote: On Mon, May 13, 2013 13:43, Dale wrote: I have it set to save a tarball here but I'd have to look up how to rescue myself if I did screw up. To rescue yourself using a binpackage: # cd / # tar -xvjpf ...path-to-binpackage-including-package... After that, I would suggest a emerge -vek world :) I have a file for things like this in my root directory. I added this one. I hope I never need it tho. ;-) I'm going to say this tho, it did not have time to compile the last gcc even tho I'm sure it did. Your mention of a genlop error may be right. I bet genlop is reporting the wrong version on one of them somehow. I wonder if genlop is noticing there are 2 GCC-compiles running, but picks the most current version for both, rather then the correct version for each emerge? That could be. It may be two different problems. Some USE flag combination triggers a infinite loop and genlop needs some Raid sprayed on it. We all know how hard it is to fix something when you have two different issues going on at the same time. To add this in case I didn't mention it. One time before, gcc compiled for like 5 or 6 hours while I took a nap. I can compile LOo several times in that time frame. Gcc never takes more than 30 minutes or so, usually around 20 or so. That depends on the USE-flags, I think. GCC on my old system always took a while, new systems (with also new versions) seem to be a lot faster. Thing is, I tend to build packages for all the machines in a single VM and then install those when I have a current set. That VM tends to be started and then I just leave it till I come back from work the next day. I don't have any VMs here. Just a regular install. I did a genlop -t gcc. There was a few that went 30 minutes and one or two that went to 32 minutes. Most likely something was compiling in parallel during a upgrade. I have it set to compile that way when it can. Having gcc compile for hours is not normal especially when gcc is compiling all by itself. In the winter I don't mind the extra heat but it's pretty much summer here now. lol I have a 4 core CPU running at I think 3.2Ghz and 16Gbs of ram with portages work directory on tmpfs. This is weird. May look into a genlop change, up to a unstable one or back to a older version. See if that helps. Got to figure out how to force a upgrade tho. ;-) Thanks. At least I seem to have a clean upgrade now. You might already had :) -- Joost Well, I like it when emerge finishes cleanly and preserved-rebuild is taken care of too. Even tho it is not really needed anymore, I still run revdep-rebuild too. Going to see what happens when it upgrades again. May need to clean out older versions of gcc that nothing really needs too. That may help. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Gcc compiling, is this normal?
On Mon, 13 May 2013 12:11:34 -0500, Dale wrote: To rescue yourself using a binpackage: # cd / # tar -xvjpf ...path-to-binpackage-including-package... After that, I would suggest a emerge -vek world :) I have a file for things like this in my root directory. I added this one. I hope I never need it tho. ;-) You should only need it if portage or python is borked. OTherwise you can leave the tarball in $PKGDIR and do emerge -1k cat/pkg -- Neil Bothwick without C people would code in Basi, Pasal and Obol signature.asc Description: PGP signature
Re: [gentoo-user] Gcc compiling, is this normal?
Neil Bothwick wrote: On Mon, 13 May 2013 12:11:34 -0500, Dale wrote: To rescue yourself using a binpackage: # cd / # tar -xvjpf ...path-to-binpackage-including-package... After that, I would suggest a emerge -vek world :) I have a file for things like this in my root directory. I added this one. I hope I never need it tho. ;-) You should only need it if portage or python is borked. OTherwise you can leave the tarball in $PKGDIR and do emerge -1k cat/pkg Yep. I have messed up portage before tho. Actually, I think I did it two or three times. Just me being me. ROFL Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Gcc compiling, is this normal?
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.mckin...@gmail.com
Re: [gentoo-user] Gcc compiling, is this normal?
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
Re: [gentoo-user] Gcc compiling, is this normal?
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
