[gentoo-dev] GCC-3.4 will be marked stable in ~1 hour on x86

[gentoo-dev] GCC-3.4 will be marked stable in ~1 hour on x86

[Mark Loeser]

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

GCC 3.4 has finally been marked stable on x86. No one will have their
compiler automatically switched to gcc-3.4 after it is installed, so you can
handle the migration to using it as your system compiler when you have time.
To assist you in the migration we have made a GCC migration guide[1].

For support issues, #gentoo is the place to receive help. Bugs found in
the course of this upgrade should be filed under the "Gentoo Linux" product,
and "GCC Porting" component on Gentoo's Bugzilla[2].


That being said, I will be committing it in approximately 1 hour, which means
you will need to wait for it to get all of the mirrors, which will take a bit
longer after that.

[1] http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml
[2] https://bugs.gentoo.org

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] GCC-3.4 will be marked stable in ~1 hour on x86

[Philip Webb]

051202 Mark Loeser wrote:
> GCC 3.4 has finally been marked stable on x86. 
 ...
> To assist you in the migration we have made a GCC migration guide[1].
 ...
> [1] http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml

This looks a model of clarity & (let's hope on the day: smile) accuracy.

After a week trying to get an OS re-installed on my 2000-built box
(it's too slow for Gentoo: finally, I got Mandrake 10.1 to work),
I'm feeling more than usually grateful to Gentoo's volunteer laborers.

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] emerge -e question Was: GCC-3.4 will be marked stable in ~1 hour on x86

[Duncan]

Mark Loeser posted <20051202215523.GA25803@aerie.halcy0n.com>, excerpted
below,  on Fri, 02 Dec 2005 16:55:23 -0500:

> [1] http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml

Reading this reminds me of a question I've had since I tried emerge -eav
world last time:

When portage merges, it stops the emerge process, updates its metadata or
whatever, then restarts the process.  With the -e in there, at least here,
it reissued the same command over again, thereby restarting the process
from the beginning and of course, upon getting to portage, looping yet
again!

I don't know how many times it looped before I decided to check on things
and figured out what was happening, at which point I was able to do an
emerge -pe and get a listing, then delete <=portage from the list and just
remerge what came after.

I've yet to see anyone else mention this, and certainly the document above
doesn't mention it as an issue when invoking emerge -e world, so that
reasonably means I experienced the loop when others don't.  Why might this
be (I know the reason for portage stopping and recalculating, but why is
it apparently not hitting others), and what can I do to prevent it the
next time I do an emerge -e world?

Maybe it was because I was using -KuD also, to remerge/upgrade from binary
packages? (Hard disk trouble, I was remerging the binary packages to
bring up2date an old installation snapshot.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] emerge -e question Was: GCC-3.4 will be marked stable in ~1 hour on x86

[Jason Stubbs]

On Saturday 03 December 2005 21:47, Duncan wrote:
> Mark Loeser posted <20051202215523.GA25803@aerie.halcy0n.com>, excerpted
>
> below,  on Fri, 02 Dec 2005 16:55:23 -0500:
> > [1] http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml
>
> Reading this reminds me of a question I've had since I tried emerge -eav
> world last time:
>
> When portage merges, it stops the emerge process, updates its metadata or
> whatever, then restarts the process.  With the -e in there, at least here,
> it reissued the same command over again, thereby restarting the process
> from the beginning and of course, upon getting to portage, looping yet
> again!

This is incorrect. Portage should only restart if the version that was merged 
does not match the internally recorded version. There was one or two releases 
that had an incorrect internal version but not for at least a year. However, 
if the version has changed and portage does restart itself then any packages 
listed before portage will be merged again.

> Maybe it was because I was using -KuD also, to remerge/upgrade from binary
> packages? (Hard disk trouble, I was remerging the binary packages to
> bring up2date an old installation snapshot.)

Perhaps you were using one of the broken versions?

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: emerge -e question Was: GCC-3.4 will be marked stable in ~1 hour on x86

[Duncan]

Jason Stubbs posted <200512041113.54555.jstubbs@gentoo.org>, excerpted
below,  on Sun, 04 Dec 2005 11:13:54 +0900:

>> Reading this reminds me of a question I've had since I tried emerge -eav
>> world last time:
>>
>> When portage merges, it stops the emerge process, updates its metadata or
>> whatever, then restarts the process.  With the -e in there, at least here,
>> it reissued the same command over again, thereby restarting the process
>> from the beginning and of course, upon getting to portage, looping yet
>> again!
> 
> This is incorrect. Portage should only restart if the version that was merged 
> does not match the internally recorded version. There was one or two releases 
> that had an incorrect internal version but not for at least a year. However, 
> if the version has changed and portage does restart itself then any packages 
> listed before portage will be merged again.
> 
>> Maybe it was because I was using -KuD also, to remerge/upgrade from binary
>> packages? (Hard disk trouble, I was remerging the binary packages to
>> bring up2date an old installation snapshot.)
> 
> Perhaps you were using one of the broken versions?

Most likely so.  At the time, the portage database was out of sync with
what was actually merged, because the database was new (on /var, which
wasn't affected) but I was working from an old root and /usr set.  Since I
had all the binary packages, I figured the easiest way to get everything
back upto-date and lined up again, was to do an emerge --emptytree
--packageonly, and I was rather frustrated to find it kept looping, when
I'd never seen anything in the documentation saying to watch out for
portage or the easiest way to avoid the loop.  =8^\

Honestly, I didn't expect it to be absolutely smooth, because that's not
"functioning within design specifications", and I knew it.  It's just that
was the only experience with emerge --emptytree I'd had, and I didn't
expect /that/ problem, because it was just too obvious not to be mentioned
if it was happening to everyone, or whatever.

Anyway, I have an explanation for what had been an unexplained anomaly,
now, and my level of peace with the world just went up accordingly, so
very much thanks!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GCC-3.4 will be marked stable in ~1 hour on x86

[Jan Kundrát]

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

On Friday 02 of December 2005 22:55 Mark Loeser wrote:
> GCC 3.4 has finally been marked stable on x86. No one will have their
> compiler automatically switched to gcc-3.4 after it is installed, so you

Unfortunately, this is not true, at least on my non-eselect-powered x86 system 
(which is default if you don't run ~x86), please see bug 114341 [3].

> [1] http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml

As a result of [1], `emerge -e system` wanted to re-emerge older version of 
GCC (3.3.6 in case of up-to-date x86 system) which would in turn become the 
default compiler. After some discussion on #-dev and #-x86, I've modified the 
guide to `emerge libstdc++-v3` before rebuilding system. This prevents 
rebuilding gcc-3.3.6 (and thus reverting back to the old compiler) as the 
gcc-3.4.4-r1's dependancy on "sys-libs/libstdc++-v3 or =sys-devel/gcc-3.3*" 
is satisfied.

[3] https://bugs.gentoo.org/show_bug.cgi?id=114341

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] gcc-3.4 migration guide

[Matthias Langer]

Well done, i've allready switched completely to gcc-3.4 with my main box
by reemerging about 650 packages. However, i allready started doing so a
few days ago, so I didn't read the official migration guide before
starting. Now, as everything works fine i just read this guide to
compair it with my own experiences as more or less simple user. 

There are two things i have to critisize:

1.) If you remove gcc-3.3* before emerge -e system you will be left
behind with a broken python and therefore emerge. Thus i think there
should be a big red box telling users about this.

2.) emerge -e world on a system with lot of packages will most likley
fail somewhere during the process for various reasons. Fixig the problem
(for example by unmerging the package which causes it) and restarting
the process is not an option, as this may cost you lot's of time. In my
case, emerge -e world stopped 3 times. To continiue without starting it
all again, i did 

# emerge --resume -p > package.list 

and then edited this file with vi so that 

# emerge --oneshot --nodeps `cat package.list` 

continued the process, leafing out the brocken package. The be honest, i
expected to find some freaky sed command to accomplish what i did with
vi (thanks to the makro recorder) in the gcc-3.4 migration guide.

Have a nice day !
Matthias



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gcc-3.4 migration guide

[Marius Mauch]

Matthias Langer wrote:
> 2.) emerge -e world on a system with lot of packages will most likley
> fail somewhere during the process for various reasons. Fixig the problem
> (for example by unmerging the package which causes it) and restarting
> the process is not an option, as this may cost you lot's of time. In my
> case, emerge -e world stopped 3 times. To continiue without starting it
> all again, i did 
> 
> # emerge --resume -p > package.list 
> 
> and then edited this file with vi so that 
> 
> # emerge --oneshot --nodeps `cat package.list` 
> 
> continued the process, leafing out the brocken package. The be honest, i
> expected to find some freaky sed command to accomplish what i did with
> vi (thanks to the makro recorder) in the gcc-3.4 migration guide.

Why not just use --resume --skipfirst?

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gcc-3.4 migration guide

[Jan Kundrát]

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

On Saturday 03 of December 2005 21:26 Matthias Langer wrote:
> 1.) If you remove gcc-3.3* before emerge -e system you will be left
> behind with a broken python and therefore emerge. Thus i think there
> should be a big red box telling users about this.

Our guide says that you have to either run `revdep-rebuild` or `emerge -1 
libstdc++-v3` and `emerge -e system` before unmerging old version of GCC.

WKR,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] gcc-3.4 migration guide

[Matthias Langer]

On Sat, 2005-12-03 at 21:31 +0100, Jan Kundrát wrote:
> On Saturday 03 of December 2005 21:26 Matthias Langer wrote:
> > 1.) If you remove gcc-3.3* before emerge -e system you will be left
> > behind with a broken python and therefore emerge. Thus i think there
> > should be a big red box telling users about this.
> 
> Our guide says that you have to either run `revdep-rebuild` or `emerge -1 
> libstdc++-v3` and `emerge -e system` before unmerging old version of GCC.

Of course you are right. I didn't say the the guide doesn't mention
this, i just said that in my opinion this should be mentioned more eye
catching, just to be sure.

> 
> WKR,
> -jkt
> 

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gcc-3.4 migration guide

[Luis F. Araujo]

Matthias Langer wrote:

>On Sat, 2005-12-03 at 21:31 +0100, Jan Kundrát wrote:
>  
>
>>On Saturday 03 of December 2005 21:26 Matthias Langer wrote:
>>    
>>
>>>1.) If you remove gcc-3.3* before emerge -e system you will be left
>>>behind with a broken python and therefore emerge. Thus i think there
>>>should be a big red box telling users about this.
>>>      
>>>
>>Our guide says that you have to either run `revdep-rebuild` or `emerge -1 
>>libstdc++-v3` and `emerge -e system` before unmerging old version of GCC.
>>    
>>
>
>Of course you are right. I didn't say the the guide doesn't mention
>this, i just said that in my opinion this should be mentioned more eye
>catching, just to be sure.
>
>  
>
I don't see anything un-important in the guide.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: gcc-3.4 migration guide

[Jeff Grossman]

Jan Kundr?t <jkt@gentoo.org> wrote:
> [-- text/plain, encoding quoted-printable, charset: utf-8, 14 lines --]
> 
> On Saturday 03 of December 2005 21:26 Matthias Langer wrote:
>> 1.) If you remove gcc-3.3* before emerge -e system you will be left
>> behind with a broken python and therefore emerge. Thus i think there
>> should be a big red box telling users about this.
> 
> Our guide says that you have to either run `revdep-rebuild` or `emerge -1 
> libstdc++-v3` and `emerge -e system` before unmerging old version of GCC.

When I read the migration document, it looks like a lowercase "L" 
instead of a number "1".  That is why the emerge did not work for me.

Jeff

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gcc-3.4 migration guide

[Joshua Baergen]

Matthias Langer wrote:
> 2.) emerge -e world on a system with lot of packages will most likley
> fail somewhere during the process for various reasons. Fixig the problem
> (for example by unmerging the package which causes it) and restarting
> the process is not an option, as this may cost you lot's of time. In my
> case, emerge -e world stopped 3 times. To continiue without starting it
> all again, i did 
>
> # emerge --resume -p > package.list 
>
> and then edited this file with vi so that 
>
> # emerge --oneshot --nodeps `cat package.list` 
>
>   
You'd probably be interested in 'emerge --resume --skipfirst'.

--
Joshua Baergen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gcc-3.4 migration guide

[Matthias Langer]

On Sat, 2005-12-03 at 14:04 -0700, Joshua Baergen wrote:
> Matthias Langer wrote:
> > 2.) emerge -e world on a system with lot of packages will most likley
> > fail somewhere during the process for various reasons. Fixig the problem
> > (for example by unmerging the package which causes it) and restarting
> > the process is not an option, as this may cost you lot's of time. In my
> > case, emerge -e world stopped 3 times. To continiue without starting it
> > all again, i did 
> >
> > # emerge --resume -p > package.list 
> >
> > and then edited this file with vi so that 
> >
> > # emerge --oneshot --nodeps `cat package.list` 
> >
> >   
> You'd probably be interested in 'emerge --resume --skipfirst'.

:-) well, this is just the kind of information i had expected to find in
the migration guide.

By the way, please don't get me wrong, i highly appreciate the hard work
you are all doing - gentoo really is a great project and my remarks here
in this list have the sole purpose to make it eaven better.

Matthias

> 
> --
> Joshua Baergen

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gcc-3.4 migration guide

[Luis F. Araujo]

Matthias Langer wrote:

>On Sat, 2005-12-03 at 14:04 -0700, Joshua Baergen wrote:
>  
>
>>Matthias Langer wrote:
>>    
>>
>>>2.) emerge -e world on a system with lot of packages will most likley
>>>fail somewhere during the process for various reasons. Fixig the problem
>>>(for example by unmerging the package which causes it) and restarting
>>>the process is not an option, as this may cost you lot's of time. In my
>>>case, emerge -e world stopped 3 times. To continiue without starting it
>>>all again, i did 
>>>
>>># emerge --resume -p > package.list 
>>>
>>>and then edited this file with vi so that 
>>>
>>># emerge --oneshot --nodeps `cat package.list` 
>>>
>>>  
>>>      
>>>
>>You'd probably be interested in 'emerge --resume --skipfirst'.
>>    
>>
>
>:-) well, this is just the kind of information i had expected to find in
>the migration guide.
>
>By the way, please don't get me wrong, i highly appreciate the hard work
>you are all doing - gentoo really is a great project and my remarks here
>in this list have the sole purpose to make it eaven better.
>  
>
I don't know if somebody recently updated it, but this is on the guide.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] gcc-3.4 migration guide

[Matthias Langer]

On Sat, 2005-12-03 at 21:38 -0400, Luis F. Araujo wrote:
> Matthias Langer wrote:
> 
> >On Sat, 2005-12-03 at 14:04 -0700, Joshua Baergen wrote:
> >  
> >
> >>Matthias Langer wrote:
> >>    
> >>
> >>>2.) emerge -e world on a system with lot of packages will most likley
> >>>fail somewhere during the process for various reasons. Fixig the problem
> >>>(for example by unmerging the package which causes it) and restarting
> >>>the process is not an option, as this may cost you lot's of time. In my
> >>>case, emerge -e world stopped 3 times. To continiue without starting it
> >>>all again, i did 
> >>>
> >>># emerge --resume -p > package.list 
> >>>
> >>>and then edited this file with vi so that 
> >>>
> >>># emerge --oneshot --nodeps `cat package.list` 
> >>>
> >>>  
> >>>      
> >>>
> >>You'd probably be interested in 'emerge --resume --skipfirst'.
> >>    
> >>
> >
> >:-) well, this is just the kind of information i had expected to find in
> >the migration guide.
> >
> >By the way, please don't get me wrong, i highly appreciate the hard work
> >you are all doing - gentoo really is a great project and my remarks here
> >in this list have the sole purpose to make it eaven better.
> >  
> >
> I don't know if somebody recently updated it, but this is on the guide.

Well, my fault - maybe i just missed that - sorry.
Matthias

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] GCC-3.4 will be marked stable in ~1 hour on x86

[Georgi Georgiev]

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

maillog: 02/12/2005-16:55:23(-0500): Mark Loeser types
> 
> [1] http://www.gentoo.org/proj/en/base/x86/gcc-upgrading-guide.xml

Re: the guide above.

It says to run 

# revdep-rebuild --library libstdc++.so.5 -- -pv
# revdep-rebuild --library libstdc++.so.5

However, revdep-rebuild only recognizes "-p" when rebuilding (it does
not recognize -pv for pretend) and it will delete the /root/.revdep*
files upon completion of the "-pv" command.  The downside is that
revdep-rebuild will need to search for the matching binaries *twice* if
a user follows the above guide.

Compare the output of:

	# revdep-rebuild --library libstdc++.so.5 -- -pv

	... <snip> ...
	Total size of downloads: 0 kB
	Build finished correctly. Removing temporary files... ..........
	You can re-run revdep-rebuild to verify that all libraries and binaries
	are fixed. If some inconsistency remains, it can be orphaned file, deep
	dependency, binary package or specially evaluated library.

And...

	# revdep-rebuild --library libstdc++.so.5 -- -p -v

	... <snip> ...
	Total size of downloads: 0 kB
	Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild.

-- 
/\   Georgi Georgiev   /\ Your boss is a few sandwiches short of a   /\
\/    chutz@gg3.net    \/ picnic.                                    \/
/\ http://www.gg3.net/ /\                                            /\

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]