lazy gcc switching
 

Hi

I've just switched to gcc 4.3.4 from 4.1.2 using gcc-config tool. I don't want
to rebuild any package now. As time goes on my packages will be compiled with
new version. I hope that after a few month there will be only a number of
packages not compiled with a new gcc. Then I want to recompile them on demand
including libtool if necessary.

Do you think my plan have a chance to succeed.

thanks for help

lazy gcc switching
 

On Wednesday 21 July 2010 10:53:19 fajfusio@wp.pl wrote:
> Hi
>
> I've just switched to gcc 4.3.4 from 4.1.2 using gcc-config tool. I don't
> want to rebuild any package now. As time goes on my packages will be
> compiled with new version. I hope that after a few month there will be
> only a number of packages not compiled with a new gcc. Then I want to
> recompile them on demand including libtool if necessary.
>
> Do you think my plan have a chance to succeed.

Yes.

Why do you think you would even need to get into a long compile? Have you been
reading that GCC Upgrade Guide at gentoo.org? You know, the one that is so
flat out wrong on so many levels?



--
alan dot mckinnon at gmail dot com

lazy gcc switching
 

Alan McKinnon wrote:

On Wednesday 21 July 2010 10:53:19 fajfusio@wp.pl wrote:


Hi

I've just switched to gcc 4.3.4 from 4.1.2 using gcc-config tool. I don't
want to rebuild any package now. As time goes on my packages will be
compiled with new version. I hope that after a few month there will be
only a number of packages not compiled with a new gcc. Then I want to
recompile them on demand including libtool if necessary.

Do you think my plan have a chance to succeed.


Yes.

Why do you think you would even need to get into a long compile? Have you been
reading that GCC Upgrade Guide at gentoo.org? You know, the one that is so
flat out wrong on so many levels?




I recently upgraded my gcc and I must confess, I did do a emerge -e
system. Is it needed, nope.


OP, Alan is correct on this. You don't really need to re-emerge
everything. If, like me, you want to be on the safe side, just do a
emerge -e system and let the rest recompile as you update.


Another good thing about this way, if this version of gcc causes you
trouble, you can downgrade and only have to re-emerge system. ;-) I
did upgrade gcc once and had serious issues with it. Wouldn't compile a
kernel, programs crashing and other weird things. After a downgrade,
all went back to normal. The only thing worse than a emerge -e world is
having to do it twice. LOL


Dale

:-) :-)

lazy gcc switching
 

On 07/21/2010 03:22 AM, Dale wrote:
> Alan McKinnon wrote:
>> On Wednesday 21 July 2010 10:53:19 fajfusio@wp.pl wrote:
>>
>>> Hi
>>>
>>> I've just switched to gcc 4.3.4 from 4.1.2 using gcc-config tool. I
>>> don't
>>> want to rebuild any package now. As time goes on my packages will be
>>> compiled with new version. I hope that after a few month there will be
>>> only a number of packages not compiled with a new gcc. Then I want to
>>> recompile them on demand including libtool if necessary.
>>>
>>> Do you think my plan have a chance to succeed.
>>>
>> Yes.
>>
>> Why do you think you would even need to get into a long compile? Have
>> you been
>> reading that GCC Upgrade Guide at gentoo.org? You know, the one that
>> is so
>> flat out wrong on so many levels?
>>
>>
>
> I recently upgraded my gcc and I must confess, I did do a emerge -e
> system. Is it needed, nope.
>
> OP, Alan is correct on this. You don't really need to re-emerge
> everything. If, like me, you want to be on the safe side, just do a
> emerge -e system and let the rest recompile as you update.
>
> Another good thing about this way, if this version of gcc causes you
> trouble, you can downgrade and only have to re-emerge system. ;-) I
> did upgrade gcc once and had serious issues with it. Wouldn't compile a
> kernel, programs crashing and other weird things. After a downgrade,
> all went back to normal. The only thing worse than a emerge -e world is
> having to do it twice. LOL

And to play devil's advocate, I'll chime in with my experience. The 4.4
GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled
all my packages after I upgraded to 4.4 and it was a *noticeable*
difference.

But, to make perfectly clear what Alan and Dale have stated previously,
it is not a requirement to recompile anything. The binaries that are
created still call the same system calls as they did before. The kernel
still publishes them in the same locations. And to prove to yourself
this is true, grab a statically linked binary, compiled for a stock
standard i686, and run it on your machine.

lazy gcc switching
 

On Wednesday 21 July 2010 17:49:46 Bill Longman wrote:
> And to play devil's advocate, I'll chime in with my experience. The 4.4
> GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled
> all my packages after I upgraded to 4.4 and it was a noticeable
> difference.
>
> But, to make perfectly clear what Alan and Dale have stated previously,
> it is not a requirement to recompile anything. The binaries that are
> created still call the same system calls as they did before. The kernel
> still publishes them in the same locations. And to prove to yourself
> this is true, grab a statically linked binary, compiled for a stock
> standard i686, and run it on your machine.

I'd love to be able to experience the speedups of gcc-4.4 and by rights I
should be able to - my last "rip gentoo apart and put it back together again"
stunt needed an emerge -e world to fix it all.

But, and this is the bit that makes me cry, the slowdown from KDE-4.4.5 has
obliterated all that advantage several times over.....

raster *really* needs to hurrry up now and release e17


--
alan dot mckinnon at gmail dot com

lazy gcc switching
 

Alan McKinnon wrote:

On Wednesday 21 July 2010 17:49:46 Bill Longman wrote:


And to play devil's advocate, I'll chime in with my experience. The 4.4
GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled
all my packages after I upgraded to 4.4 and it was a noticeable
difference.

But, to make perfectly clear what Alan and Dale have stated previously,
it is not a requirement to recompile anything. The binaries that are
created still call the same system calls as they did before. The kernel
still publishes them in the same locations. And to prove to yourself
this is true, grab a statically linked binary, compiled for a stock
standard i686, and run it on your machine.


I'd love to be able to experience the speedups of gcc-4.4 and by rights I
should be able to - my last "rip gentoo apart and put it back together again"
stunt needed an emerge -e world to fix it all.

But, and this is the bit that makes me cry, the slowdown from KDE-4.4.5 has
obliterated all that advantage several times over.....

raster *really* needs to hurrry up now and release e17




My last KDE upgrade made KDE a little faster here as well. It won't be
as fast as e17 tho. Since I upgraded gcc a little before that, I wasn't
sure if it was gcc building better code or KDE got rid of some garbage.
It is a little faster tho.


I suspect gcc. When as larger programs ever got faster? I'm sure they
added code to KDE, not taking code away. ;-)


Dale

:-) :-)

lazy gcc switching
 

On 07/21/2010 12:39 PM, Alan McKinnon wrote:
> On Wednesday 21 July 2010 17:49:46 Bill Longman wrote:
>> And to play devil's advocate, I'll chime in with my experience. The 4.4
>> GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled
>> all my packages after I upgraded to 4.4 and it was a noticeable
>> difference.
>>
>> But, to make perfectly clear what Alan and Dale have stated previously,
>> it is not a requirement to recompile anything. The binaries that are
>> created still call the same system calls as they did before. The kernel
>> still publishes them in the same locations. And to prove to yourself
>> this is true, grab a statically linked binary, compiled for a stock
>> standard i686, and run it on your machine.
>
> I'd love to be able to experience the speedups of gcc-4.4 and by rights I
> should be able to - my last "rip gentoo apart and put it back together again"
> stunt needed an emerge -e world to fix it all.
>
> But, and this is the bit that makes me cry, the slowdown from KDE-4.4.5 has
> obliterated all that advantage several times over.....
>
> raster *really* needs to hurrry up now and release e17

Might I suggest a small hardware upgrade:

http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F.cfm

lazy gcc switching
 

On Wed, Jul 21, 2010 at 03:36:33PM -0500, Dale wrote

> My last KDE upgrade made KDE a little faster here as well. It won't be
> as fast as e17 tho. Since I upgraded gcc a little before that, I wasn't
> sure if it was gcc building better code or KDE got rid of some garbage.
> It is a little faster tho.
>
> I suspect gcc. When as larger programs ever got faster? I'm sure they
> added code to KDE, not taking code away. ;-)

I have a neutral attitude in the KDE/GNOME battle... the pox on both
your houses<g>. I don't run desktops, I run applications. KDE/GNOME
represent a lot of why I left Windows in the first place.

--
Walter Dnes <waltdnes@waltdnes.org>

lazy gcc switching
 

On Thursday 22 July 2010 00:18:05 Bill Longman wrote:
> On 07/21/2010 12:39 PM, Alan McKinnon wrote:
> > On Wednesday 21 July 2010 17:49:46 Bill Longman wrote:
> >> And to play devil's advocate, I'll chime in with my experience. The 4.4
> >> GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled
> >> all my packages after I upgraded to 4.4 and it was a noticeable
> >> difference.
> >>
> >> But, to make perfectly clear what Alan and Dale have stated previously,
> >> it is not a requirement to recompile anything. The binaries that are
> >> created still call the same system calls as they did before. The kernel
> >> still publishes them in the same locations. And to prove to yourself
> >> this is true, grab a statically linked binary, compiled for a stock
> >> standard i686, and run it on your machine.
> >
> > I'd love to be able to experience the speedups of gcc-4.4 and by rights I
> > should be able to - my last "rip gentoo apart and put it back together
> > again" stunt needed an emerge -e world to fix it all.
> >
> > But, and this is the bit that makes me cry, the slowdown from KDE-4.4.5
> > has obliterated all that advantage several times over.....
> >
> > raster *really* needs to hurrry up now and release e17
>
> Might I suggest a small hardware upgrade:
>
> http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F.cfm

Might I submit that that will be a tad difficult to squeez into this:

# dmidecode | grep -B3 "Product Name"
Handle 0x0100, DMI type 1, 27 bytes
System Information
Manufacturer: Dell Inc.
Product Name: XPS M1530


:-)


--
alan dot mckinnon at gmail dot com

lazy gcc switching
 

Alan McKinnon wrote:

On Thursday 22 July 2010 00:18:05 Bill Longman wrote:


On 07/21/2010 12:39 PM, Alan McKinnon wrote:


On Wednesday 21 July 2010 17:49:46 Bill Longman wrote:


And to play devil's advocate, I'll chime in with my experience. The 4.4
GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled
all my packages after I upgraded to 4.4 and it was a noticeable
difference.

But, to make perfectly clear what Alan and Dale have stated previously,
it is not a requirement to recompile anything. The binaries that are
created still call the same system calls as they did before. The kernel
still publishes them in the same locations. And to prove to yourself
this is true, grab a statically linked binary, compiled for a stock
standard i686, and run it on your machine.


I'd love to be able to experience the speedups of gcc-4.4 and by rights I
should be able to - my last "rip gentoo apart and put it back together
again" stunt needed an emerge -e world to fix it all.

But, and this is the bit that makes me cry, the slowdown from KDE-4.4.5
has obliterated all that advantage several times over.....

raster *really* needs to hurrry up now and release e17


Might I suggest a small hardware upgrade:

http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F.cfm


Might I submit that that will be a tad difficult to squeez into this:

# dmidecode | grep -B3 "Product Name"
Handle 0x0100, DMI type 1, 27 bytes
System Information
Manufacturer: Dell Inc.
Product Name: XPS M1530


:-)




Heck, the mobo most likely cost more than your whole laptop. Froogle
reports over $700.00 for that thing. O_O I wouldn't want the light
bill for that thing tho. I would like to see foldingathome running on
it. LOL Gkrellm would be fun to watch.


Dale

:-) :-)