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

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

[Dale]

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. 

Thanks.

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?

[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@gmail.com

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

[David Relson]

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

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

[Dale]

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!

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

[Alan McKinnon]

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

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

[Alan McKinnon]

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

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

[Dale]

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?

[J. Roeleveld]

Dale <rdalek1967@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?

[Dale]

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]

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?

[J. Roeleveld]

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?

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

Am Mon, 13 May 2013 13:21:37 +0200
schrieb "J. Roeleveld" <joost@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Dale]

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?

[Dale]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

Marc Joliet wrote:
> Am Mon, 13 May 2013 13:21:37 +0200
> schrieb "J. Roeleveld" <joost@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!


[-- Attachment #2: Type: text/html, Size: 1930 bytes --]

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

[J. Roeleveld]

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?

[Peter Humphrey]

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?

[Dale]

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?

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Dale]

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!