[gentoo-user] Upgrading gcc: both 4.4 and 4.5 needed?

[gentoo-user] Upgrading gcc: both 4.4 and 4.5 needed?

[Jarry]

Hi,
today I upgraded gcc from 4.4.5 to the last stable version
4.5.3-r1. I followed "Gentoo GCC Upgrade Guide":

# emerge -uav gcc
# gcc-config 2
# env-update && source /etc/profile
# emerge --oneshot libtool

# emerge --depclean
# revdep-rebuild

But at the and I noticed gcc 4.4 has not been unmerged
and my "world" file is somehow larger. To my surprise,
it contains these lines:

sys-devel/gcc
sys-devel/gcc:4.4

I did full backup before, so I compared world-file before
and after gcc-upgrade just to find out, these two lines
have been really inserted now, during gcc-upgrade. And my
question is: what does it mean? Does my system need now
both gcc 4.4 and 4.5? Why is actually gcc in world-file,
when it is part of system?

Jarry

-- 
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

Re: [gentoo-user] Upgrading gcc: both 4.4 and 4.5 needed?

[Andrey Moshbear]

On Tue, Nov 15, 2011 at 13:58, Jarry <mr.jarry@gmail.com> wrote:
> Hi,
> today I upgraded gcc from 4.4.5 to the last stable version
> 4.5.3-r1. I followed "Gentoo GCC Upgrade Guide":
>
> # emerge -uav gcc
> # gcc-config 2
> # env-update && source /etc/profile
> # emerge --oneshot libtool
>
> # emerge --depclean
> # revdep-rebuild
>
> But at the and I noticed gcc 4.4 has not been unmerged
> and my "world" file is somehow larger. To my surprise,
> it contains these lines:
>
> sys-devel/gcc
> sys-devel/gcc:4.4
>
> I did full backup before, so I compared world-file before
> and after gcc-upgrade just to find out, these two lines
> have been really inserted now, during gcc-upgrade. And my
> question is: what does it mean? Does my system need now
> both gcc 4.4 and 4.5? Why is actually gcc in world-file,
> when it is part of system?
>

Because your forgot the -1 / --oneshot flag when manually upgrading gcc.
However, in system, multiple gcc slots do  not exist, so if you need gcc:4.4 for
backwards compatibility or gcc:4.6 for forwards compatibility, it'll show up in
your world file.

Re: [gentoo-user] Upgrading gcc: both 4.4 and 4.5 needed?

[Jarry]

On 15-Nov-11 20:36, Andrey Moshbear wrote:
> On Tue, Nov 15, 2011 at 13:58, Jarry<mr.jarry@gmail.com>  wrote:
>> today I upgraded gcc from 4.4.5 to the last stable version
>> But at the and I noticed gcc 4.4 has not been unmerged
>> and my "world" file is somehow larger. To my surprise,
>> it contains these lines:
>>
>> sys-devel/gcc
>> sys-devel/gcc:4.4
>>
>
> Because your forgot the -1 / --oneshot flag when manually upgrading gcc.

Hm, I always thought "--oneshot" was not necessary when
doing update. Even "Gentoo GCC Upgrade Guide" says just
"emerge -u gcc" (or "emerge -uav gcc" in DE-version).
The option "--oneshot" is used there only for libtool.

And I'm pretty sure I've never used "--oneshot" when
updating any packages, yet they have never been added
to world-file...

Jarry






-- 
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

Re: [gentoo-user] Upgrading gcc: both 4.4 and 4.5 needed?

[Dale]

Jarry wrote:
> On 15-Nov-11 20:36, Andrey Moshbear wrote:
>> On Tue, Nov 15, 2011 at 13:58, Jarry<mr.jarry@gmail.com>  wrote:
>>> today I upgraded gcc from 4.4.5 to the last stable version
>>> But at the and I noticed gcc 4.4 has not been unmerged
>>> and my "world" file is somehow larger. To my surprise,
>>> it contains these lines:
>>>
>>> sys-devel/gcc
>>> sys-devel/gcc:4.4
>>>
>>
>> Because your forgot the -1 / --oneshot flag when manually upgrading gcc.
>
> Hm, I always thought "--oneshot" was not necessary when
> doing update. Even "Gentoo GCC Upgrade Guide" says just
> "emerge -u gcc" (or "emerge -uav gcc" in DE-version).
> The option "--oneshot" is used there only for libtool.
>
> And I'm pretty sure I've never used "--oneshot" when
> updating any packages, yet they have never been added
> to world-file...
>
> Jarry
>
>

I think you are correct.  When you use the -u option, it shouldn't add 
anything to the world file.  Than again, weird things happen from time 
to time.  Take the two entries out and see what emerge says to a emerge 
-uavDN world which should catch about everything.  Then see what -a 
--depclean says.  If it tries to remove the older version then that may 
be why it was added.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Upgrading gcc: both 4.4 and 4.5 needed?

[Alex Schuster]

Jarry writes:

> On 15-Nov-11 20:36, Andrey Moshbear wrote:
>> On Tue, Nov 15, 2011 at 13:58, Jarry<mr.jarry@gmail.com>  wrote:
>>> today I upgraded gcc from 4.4.5 to the last stable version
>>> But at the and I noticed gcc 4.4 has not been unmerged
>>> and my "world" file is somehow larger. To my surprise,
>>> it contains these lines:
>>>
>>> sys-devel/gcc
>>> sys-devel/gcc:4.4
>>
>> Because your forgot the -1 / --oneshot flag when manually upgrading gcc.
> 
> Hm, I always thought "--oneshot" was not necessary when
> doing update. Even "Gentoo GCC Upgrade Guide" says just
> "emerge -u gcc" (or "emerge -uav gcc" in DE-version).
> The option "--oneshot" is used there only for libtool.
> 
> And I'm pretty sure I've never used "--oneshot" when
> updating any packages, yet they have never been added
> to world-file...

Nope. Just try again with a small package, as I just did, emerge -u will
add it to the world file. This has not always been the case, but it has
been changed at least some years ago. I'm using the newest portage, but
I believe the stable portage works the same.

	Wonko

Re: [gentoo-user] Upgrading gcc: both 4.4 and 4.5 needed?

[Dale]

Alex Schuster wrote:
> Jarry writes:
>
>> On 15-Nov-11 20:36, Andrey Moshbear wrote:
>>> On Tue, Nov 15, 2011 at 13:58, Jarry<mr.jarry@gmail.com>   wrote:
>>>> today I upgraded gcc from 4.4.5 to the last stable version
>>>> But at the and I noticed gcc 4.4 has not been unmerged
>>>> and my "world" file is somehow larger. To my surprise,
>>>> it contains these lines:
>>>>
>>>> sys-devel/gcc
>>>> sys-devel/gcc:4.4
>>> Because your forgot the -1 / --oneshot flag when manually upgrading gcc.
>> Hm, I always thought "--oneshot" was not necessary when
>> doing update. Even "Gentoo GCC Upgrade Guide" says just
>> "emerge -u gcc" (or "emerge -uav gcc" in DE-version).
>> The option "--oneshot" is used there only for libtool.
>>
>> And I'm pretty sure I've never used "--oneshot" when
>> updating any packages, yet they have never been added
>> to world-file...
> Nope. Just try again with a small package, as I just did, emerge -u will
> add it to the world file. This has not always been the case, but it has
> been changed at least some years ago. I'm using the newest portage, but
> I believe the stable portage works the same.
>
> 	Wonko
>
>


I tested this and it does add it to the world file.

root@fireball / # emerge -uv kwrite

These are the packages that would be merged, in order:

Calculating dependencies... done!

Total: 0 packages, Size of downloads: 0 kB

  * kde-base/kwrite

 >>> Recording kde-base/kwrite in "world" favorites file...
 >>> Jobs: 0 of 0 complete                           Load avg: 0.76, 
0.39, 0.30
 >>> Auto-cleaning packages...

 >>> No outdated packages were found on your system.
root@fireball / #

Then this:

root@fireball / # cat /var/lib/portage/world | grep kwrite
kde-base/kwrite
root@fireball / #

Is this a bug?  Just because you update a package doesn't mean you want 
it in the world file.

Maybe a I need to set --oneshot in make.conf and just use -n when I 
really want something in the world file.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Re: [gentoo-user] Upgrading gcc: both 4.4 and 4.5 needed?

[Mark Knecht]

On Wed, Nov 16, 2011 at 11:26 AM, Dale <rdalek1967@gmail.com> wrote:
<SNIP>
>
> root@fireball / # cat /var/lib/portage/world | grep kwrite
> kde-base/kwrite
> root@fireball / #
>
> Is this a bug?  Just because you update a package doesn't mean you want it
> in the world file.
>
> Maybe a I need to set --oneshot in make.conf and just use -n when I really
> want something in the world file.

You must use --oneshot or -1 to stop it from doing that.

HTH,
Mark

[gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Nikos Chantziaras]

On 11/15/2011 08:58 PM, Jarry wrote:
> Hi,
> today I upgraded gcc from 4.4.5 to the last stable version
> 4.5.3-r1.
>[...]
> But at the and I noticed gcc 4.4 has not been unmerged
> and my "world" file is somehow larger. To my surprise,
> it contains these lines:
>
> sys-devel/gcc
> sys-devel/gcc:4.4
>
> I did full backup before, so I compared world-file before
> and after gcc-upgrade just to find out, these two lines
> have been really inserted now, during gcc-upgrade. And my
> question is: what does it mean? Does my system need now
> both gcc 4.4 and 4.5? Why is actually gcc in world-file,
> when it is part of system?

The old GCC version does not get removed.  This is a good thing just in 
case the new one doesn't work for some reason.

If it works OK, you can manually unmerge the old version:

   emerge -aC gcc:4.4

Before doing that, however, make sure the new one has been activated 
with gcc-config and verify that it works by building some random package.

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Pandu Poluan]

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

On Nov 16, 2011 8:00 AM, "Nikos Chantziaras" <realnc@arcor.de> wrote:
>
> On 11/15/2011 08:58 PM, Jarry wrote:
>>
>> Hi,
>> today I upgraded gcc from 4.4.5 to the last stable version
>> 4.5.3-r1.
>> [...]
>>
>> But at the and I noticed gcc 4.4 has not been unmerged
>> and my "world" file is somehow larger. To my surprise,
>> it contains these lines:
>>
>> sys-devel/gcc
>> sys-devel/gcc:4.4
>>
>> I did full backup before, so I compared world-file before
>> and after gcc-upgrade just to find out, these two lines
>> have been really inserted now, during gcc-upgrade. And my
>> question is: what does it mean? Does my system need now
>> both gcc 4.4 and 4.5? Why is actually gcc in world-file,
>> when it is part of system?
>
>
> The old GCC version does not get removed.  This is a good thing just in
case the new one doesn't work for some reason.
>
> If it works OK, you can manually unmerge the old version:
>
>  emerge -aC gcc:4.4
>
> Before doing that, however, make sure the new one has been activated with
gcc-config and verify that it works by building some random package.
>

And if you're adventurous, add USE "graphite", reemerge gcc, and reemerge
world :)

Rgds,

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

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Stéphane Guedon]

[-- Attachment #1: Type: Text/Plain, Size: 1597 bytes --]

On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote:
> On Nov 16, 2011 8:00 AM, "Nikos Chantziaras" <realnc@arcor.de> wrote:
> > On 11/15/2011 08:58 PM, Jarry wrote:
> >> Hi,
> >> today I upgraded gcc from 4.4.5 to the last stable version
> >> 4.5.3-r1.
> >> [...]
> >> 
> >> But at the and I noticed gcc 4.4 has not been unmerged
> >> and my "world" file is somehow larger. To my surprise,
> >> it contains these lines:
> >> 
> >> sys-devel/gcc
> >> sys-devel/gcc:4.4
> >> 
> >> I did full backup before, so I compared world-file before
> >> and after gcc-upgrade just to find out, these two lines
> >> have been really inserted now, during gcc-upgrade. And my
> >> question is: what does it mean? Does my system need now
> >> both gcc 4.4 and 4.5? Why is actually gcc in world-file,
> >> when it is part of system?
> > 
> > The old GCC version does not get removed.  This is a good thing just in
> 
> case the new one doesn't work for some reason.
> 
> > If it works OK, you can manually unmerge the old version:
> >  emerge -aC gcc:4.4
> > 
> > Before doing that, however, make sure the new one has been activated with
> 
> gcc-config and verify that it works by building some random package.
> 
> 
> And if you're adventurous, add USE "graphite", reemerge gcc, and reemerge
> world :)
> 
> Rgds,

what does "graphite" add ?

thanks

-- 
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Andrey Moshbear]

On Wed, Nov 16, 2011 at 02:11, Stéphane Guedon <stephane@22decembre.eu> wrote:
> On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote:
>> On Nov 16, 2011 8:00 AM, "Nikos Chantziaras" <realnc@arcor.de> wrote:
>> > On 11/15/2011 08:58 PM, Jarry wrote:
>> >> Hi,
>> >> today I upgraded gcc from 4.4.5 to the last stable version
>> >> 4.5.3-r1.
>> >> [...]
>> >>
>> >> But at the and I noticed gcc 4.4 has not been unmerged
>> >> and my "world" file is somehow larger. To my surprise,
>> >> it contains these lines:
>> >>
>> >> sys-devel/gcc
>> >> sys-devel/gcc:4.4
>> >>
>> >> I did full backup before, so I compared world-file before
>> >> and after gcc-upgrade just to find out, these two lines
>> >> have been really inserted now, during gcc-upgrade. And my
>> >> question is: what does it mean? Does my system need now
>> >> both gcc 4.4 and 4.5? Why is actually gcc in world-file,
>> >> when it is part of system?
>> >
>> > The old GCC version does not get removed.  This is a good thing just in
>>
>> case the new one doesn't work for some reason.
>>
>> > If it works OK, you can manually unmerge the old version:
>> >  emerge -aC gcc:4.4
>> >
>> > Before doing that, however, make sure the new one has been activated with
>>
>> gcc-config and verify that it works by building some random package.
>>
>>
>> And if you're adventurous, add USE "graphite", reemerge gcc, and reemerge
>> world :)
>>
>> Rgds,
>
> what does "graphite" add ?
>

andrey@robot9000 /tmp $ grep graphite /usr/portage/profiles/use*.desc
/usr/portage/profiles/use.local.desc:app-office/libreoffice:graphite -
Enable support for non-Roman fonts via media-gfx/graphite2
/usr/portage/profiles/use.local.desc:app-portage/eix:strong-optimization
- Adds several more agressive CXXFLAGS/LDFLAGS for optimization like
graphite (if available). May cause trouble with some buggy compiler
versions. Absense of this USE flag does not strip user's *FLAGS
/usr/portage/profiles/use.local.desc:media-libs/harfbuzz:graphite -
Enable support for non-Roman fonts via media-gfx/graphite2
/usr/portage/profiles/use.local.desc:media-libs/silgraphite:pango -
Enables the pango-graphite pango module.
/usr/portage/profiles/use.local.desc:sys-devel/gcc:graphite - Add
support for the framework for loop optimizations based on a polyhedral
intermediate representation

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Michael Mol]

On Wed, Nov 16, 2011 at 2:11 AM, Stéphane Guedon <stephane@22decembre.eu> wrote:
> On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote:
>> And if you're adventurous, add USE "graphite", reemerge gcc, and reemerge
>> world :)
>
> what does "graphite" add ?

Thanks for reminding me; I meant to look it up when I got home.

shortcircuit:1@serenity~
Wed Nov 16 02:16 AM
!501 #1 j0 ?0 $ euse -i graphite
global use flags (searching: graphite)
************************************************************
no matching entries found

local use flags (searching: graphite)
************************************************************

[snip]

[-      ] graphite
    sys-devel/gcc: Add support for the framework for loop optimizations
    based on a polyhedral intermediate representation

So, a new, experimental optimization model and framework inside your
compiler. If it's specifically for optimizing on loops, I'll venture a
guess it's going to be mostly effective for graphics libraries and
apps. I've got some slightly riskier educated guesses on how it works
and what some numeric side effects and consequences might be, but they
scare me, so I think I'll leave it to someone who actually knows more
about it...

-- 
:wq

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Pandu Poluan]

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

On Nov 16, 2011 2:26 PM, "Michael Mol" <mikemol@gmail.com> wrote:
>
> On Wed, Nov 16, 2011 at 2:11 AM, Stéphane Guedon <stephane@22decembre.eu>
wrote:
> > On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote:
> >> And if you're adventurous, add USE "graphite", reemerge gcc, and
reemerge
> >> world :)
> >
> > what does "graphite" add ?
>
> Thanks for reminding me; I meant to look it up when I got home.
>
> shortcircuit:1@serenity~
> Wed Nov 16 02:16 AM
> !501 #1 j0 ?0 $ euse -i graphite
> global use flags (searching: graphite)
> ************************************************************
> no matching entries found
>
> local use flags (searching: graphite)
> ************************************************************
>
> [snip]
>
> [-      ] graphite
>    sys-devel/gcc: Add support for the framework for loop optimizations
>    based on a polyhedral intermediate representation
>
> So, a new, experimental optimization model and framework inside your
> compiler. If it's specifically for optimizing on loops, I'll venture a
> guess it's going to be mostly effective for graphics libraries and
> apps. I've got some slightly riskier educated guesses on how it works
> and what some numeric side effects and consequences might be, but they
> scare me, so I think I'll leave it to someone who actually knows more
> about it...
>

I've been using USE "graphite" since gcc-4.5.3-r1 appeared. Upstream says
that graphite is stable, feature-complete, and production-ready since 4.5.3.

To fully taste the effect of graphite, I even went the torturous route of
emerging gcc + libtool + binutils (in that order) twice, followed by a
wholesale-rebuild of everything (emerge --emptytree), then tarballed the
result to my own "stage3.1" tarball to spare me the *huge* amount of time
required.

I've deployed 3 systems with USE "graphite", and they *felt* snappier.
emerge's *felt* slower, though. (no objective tests, I know).

I use Gentoo as a gatewall, and there I did a wholesale-rebuild one more
time, this time specifying CFLAGS "-march=native"... and I just couldn't be
happier with the resulting performance :-)

Rgds,

Rgds,

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

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Fredric Johansson]

On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Nov 16, 2011 2:26 PM, "Michael Mol" <mikemol@gmail.com> wrote:
>>
>> On Wed, Nov 16, 2011 at 2:11 AM, Stéphane Guedon <stephane@22decembre.eu>
>> wrote:
>> > On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote:
>> >> And if you're adventurous, add USE "graphite", reemerge gcc, and
>> >> reemerge
>> >> world :)
>> >
>> > what does "graphite" add ?
>>
>> Thanks for reminding me; I meant to look it up when I got home.
>>
>> shortcircuit:1@serenity~
>> Wed Nov 16 02:16 AM
>> !501 #1 j0 ?0 $ euse -i graphite
>> global use flags (searching: graphite)
>> ************************************************************
>> no matching entries found
>>
>> local use flags (searching: graphite)
>> ************************************************************
>>
>> [snip]
>>
>> [-      ] graphite
>>    sys-devel/gcc: Add support for the framework for loop optimizations
>>    based on a polyhedral intermediate representation
>>
>> So, a new, experimental optimization model and framework inside your
>> compiler. If it's specifically for optimizing on loops, I'll venture a
>> guess it's going to be mostly effective for graphics libraries and
>> apps. I've got some slightly riskier educated guesses on how it works
>> and what some numeric side effects and consequences might be, but they
>> scare me, so I think I'll leave it to someone who actually knows more
>> about it...
>>
>
> I've been using USE "graphite" since gcc-4.5.3-r1 appeared. Upstream says
> that graphite is stable, feature-complete, and production-ready since 4.5.3.
>
> To fully taste the effect of graphite, I even went the torturous route of
> emerging gcc + libtool + binutils (in that order) twice, followed by a
> wholesale-rebuild of everything (emerge --emptytree), then tarballed the
> result to my own "stage3.1" tarball to spare me the *huge* amount of time
> required.
>
> I've deployed 3 systems with USE "graphite", and they *felt* snappier.
> emerge's *felt* slower, though. (no objective tests, I know).
>
> I use Gentoo as a gatewall, and there I did a wholesale-rebuild one more
> time, this time specifying CFLAGS "-march=native"... and I just couldn't be
> happier with the resulting performance :-)
>
> Rgds,
>

I might be wrong but don't you need to have the gcc's options for
graphite enabled to actually make use of the graphite framework? (You
might be using them but you haven't mentioned it.)

//Fredric

//Fredric

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Pandu Poluan]

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

On Nov 18, 2011 10:41 PM, "Fredric Johansson" <fredric.miscmail@gmail.com>
wrote:
>
> On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan <pandu@poluan.info> wrote:
> >
> > On Nov 16, 2011 2:26 PM, "Michael Mol" <mikemol@gmail.com> wrote:
> >>
> >> On Wed, Nov 16, 2011 at 2:11 AM, Stéphane Guedon <
stephane@22decembre.eu>
> >> wrote:
> >> > On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote:
> >> >> And if you're adventurous, add USE "graphite", reemerge gcc, and
> >> >> reemerge
> >> >> world :)
> >> >
> >> > what does "graphite" add ?
> >>
> >> Thanks for reminding me; I meant to look it up when I got home.
> >>
> >> shortcircuit:1@serenity~
> >> Wed Nov 16 02:16 AM
> >> !501 #1 j0 ?0 $ euse -i graphite
> >> global use flags (searching: graphite)
> >> ************************************************************
> >> no matching entries found
> >>
> >> local use flags (searching: graphite)
> >> ************************************************************
> >>
> >> [snip]
> >>
> >> [-      ] graphite
> >>    sys-devel/gcc: Add support for the framework for loop optimizations
> >>    based on a polyhedral intermediate representation
> >>
> >> So, a new, experimental optimization model and framework inside your
> >> compiler. If it's specifically for optimizing on loops, I'll venture a
> >> guess it's going to be mostly effective for graphics libraries and
> >> apps. I've got some slightly riskier educated guesses on how it works
> >> and what some numeric side effects and consequences might be, but they
> >> scare me, so I think I'll leave it to someone who actually knows more
> >> about it...
> >>
> >
> > I've been using USE "graphite" since gcc-4.5.3-r1 appeared. Upstream
says
> > that graphite is stable, feature-complete, and production-ready since
4.5.3.
> >
> > To fully taste the effect of graphite, I even went the torturous route
of
> > emerging gcc + libtool + binutils (in that order) twice, followed by a
> > wholesale-rebuild of everything (emerge --emptytree), then tarballed the
> > result to my own "stage3.1" tarball to spare me the *huge* amount of
time
> > required.
> >
> > I've deployed 3 systems with USE "graphite", and they *felt* snappier.
> > emerge's *felt* slower, though. (no objective tests, I know).
> >
> > I use Gentoo as a gatewall, and there I did a wholesale-rebuild one more
> > time, this time specifying CFLAGS "-march=native"... and I just
couldn't be
> > happier with the resulting performance :-)
> >
> > Rgds,
> >
>
> I might be wrong but don't you need to have the gcc's options for
> graphite enabled to actually make use of the graphite framework? (You
> might be using them but you haven't mentioned it.)
>

Yes. There are some CFLAGS incantations to add to fully utilize graphite,
else the optimizations would be marginal at best.

That said, turning on the CFLAGS flags was a *very* involved process:

1. By default, "graphite" is disabled. So you can't directly turn on the
graphite-related CFLAGS option. You must first enable USE "graphite" and
re-emerge gcc (or upgrade, if you're still using <gcc-4.5.3). This will
pull in ppl and cloog-ppl.

2. I don't know if libtool and binutils need to be remerged, but I did it
just to be safe.

3. Now that gcc has been compiled with graphite support, you can turn on
the CFLAGS flags necessary to fully utilize graphite. WARNING: some flags
recommended by upstream *might* make some programs run worse; be careful.
(I won't have access to my servers so I can't tell you which ones exactly).

4. At this point, I want gcc itself to be optimized. So, I remerged gcc and
libtool and binutils (in that order). Might be unnecessary, but I'm anal
like that :-)

5. Finally, universe-remerge (emerge --emptytree).

As you can see, steps 4 & 5 are optional. And they indeed took a
*humongous* time to complete. But I am quite satisfied with the result.
Everything felt snappier compared to older boxen that haven't been
graphite-ed :-)

Of course, YMMV.

Rgds,

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

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Pandu Poluan]

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

On Nov 18, 2011 11:35 PM, "Pandu Poluan" <pandu@poluan.info> wrote:
>
>
> On Nov 18, 2011 10:41 PM, "Fredric Johansson" <fredric.miscmail@gmail.com>
wrote:
> >
> > On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan <pandu@poluan.info> wrote:
> > >

-----snip

> > >
> > > I've been using USE "graphite" since gcc-4.5.3-r1 appeared. Upstream
says
> > > that graphite is stable, feature-complete, and production-ready since
4.5.3.
> > >
> > > To fully taste the effect of graphite, I even went the torturous
route of
> > > emerging gcc + libtool + binutils (in that order) twice, followed by a
> > > wholesale-rebuild of everything (emerge --emptytree), then tarballed
the
> > > result to my own "stage3.1" tarball to spare me the *huge* amount of
time
> > > required.
> > >
> > > I've deployed 3 systems with USE "graphite", and they *felt* snappier.
> > > emerge's *felt* slower, though. (no objective tests, I know).
> > >
> > > I use Gentoo as a gatewall, and there I did a wholesale-rebuild one
more
> > > time, this time specifying CFLAGS "-march=native"... and I just
couldn't be
> > > happier with the resulting performance :-)
> > >
> > > Rgds,
> > >
> >
> > I might be wrong but don't you need to have the gcc's options for
> > graphite enabled to actually make use of the graphite framework? (You
> > might be using them but you haven't mentioned it.)
> >
>
> Yes. There are some CFLAGS incantations to add to fully utilize graphite,
else the optimizations would be marginal at best.
>
> That said, turning on the CFLAGS flags was a *very* involved process:
>
> 1. By default, "graphite" is disabled. So you can't directly turn on the
graphite-related CFLAGS option. You must first enable USE "graphite" and
re-emerge gcc (or upgrade, if you're still using <gcc-4.5.3). This will
pull in ppl and cloog-ppl.
>
> 2. I don't know if libtool and binutils need to be remerged, but I did it
just to be safe.
>
> 3. Now that gcc has been compiled with graphite support, you can turn on
the CFLAGS flags necessary to fully utilize graphite. WARNING: some flags
recommended by upstream *might* make some programs run worse; be careful.
(I won't have access to my servers so I can't tell you which ones exactly).
>
> 4. At this point, I want gcc itself to be optimized. So, I remerged gcc
and libtool and binutils (in that order). Might be unnecessary, but I'm
anal like that :-)
>
> 5. Finally, universe-remerge (emerge --emptytree).
>
> As you can see, steps 4 & 5 are optional. And they indeed took a
*humongous* time to complete. But I am quite satisfied with the result.
Everything felt snappier compared to older boxen that haven't been
graphite-ed :-)
>
> Of course, YMMV.
>

Okay, found a forum thread discussing graphite and the proper CFLAGS:

http://forums.gentoo.org/viewtopic-t-850087.html

IIRC my CFLAGS looks very similar to the once @genstorm uses (scroll down
to approximately 80% down the page).

Now I never experienced *any* emerge failure, provided that I don't go
higher than MAKEOPTS="-j3". Set it higher and several packages failed
during compile. I don't know whose fault is that, but you've been warned
;-)

Rgds,

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

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Pandu Poluan]

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

On Nov 16, 2011 2:15 PM, "Stéphane Guedon" <stephane@22decembre.eu> wrote:
>
> On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote:
> >
> > And if you're adventurous, add USE "graphite", reemerge gcc, and
reemerge
> > world :)
> >
> > Rgds,
>
> what does "graphite" add ?
>
> thanks
>

It makes gcc-4.5.3 use a newer method to detect parallelism, thus
(potentially) makes programs compiled by gcc to have better multithreaded
performance.

Rgds,

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

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Willie Wong]

On Wed, Nov 16, 2011 at 03:29:27PM +0700, Pandu Poluan wrote:
> > what does "graphite" add ?
> >
> 
> It makes gcc-4.5.3 use a newer method to detect parallelism, thus
> (potentially) makes programs compiled by gcc to have better multithreaded
> performance.

Now, why can't the USE descriptions be like the kernel option
descriptions and have something like what Pandu wrote included? 

W

-- 
Willie W. Wong                                     wwong@math.princeton.edu
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
         et vice versa   ~~~  I. Newton

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Albert W. Hopkins]

On Wed, 2011-11-16 at 08:30 -0500, Willie Wong wrote:
> On Wed, Nov 16, 2011 at 03:29:27PM +0700, Pandu Poluan wrote:
> > > what does "graphite" add ?
> > >
> > 
> > It makes gcc-4.5.3 use a newer method to detect parallelism, thus
> > (potentially) makes programs compiled by gcc to have better multithreaded
> > performance.
> 
> Now, why can't the USE descriptions be like the kernel option
> descriptions and have something like what Pandu wrote included? 

$ equery u gcc
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for sys-devel/gcc-4.5.3-r1:
 U I
 - - bootstrap : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!,
used
                 during original system bootstrapping [make stage2]
 - - build     : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!,
used for
                 creating build images and the first half of
bootstrapping
                 [make stage1]
 + + cxx       : Builds support for C++ (bindings, extra libraries, code
                 generation, ...)
 - - doc       : Adds extra documentation (API, Javadoc, etc). It is
                 recommended to enable per package instead of globally
 - - fortran   : Adds support for fortran (formerly f77)
 - - gcj       : Enable building with gcj (The GNU Compiler for the
Javatm
                 Programming Language)
 - - graphite  : Add support for the framework for loop optimizations
based on
                 a polyhedral intermediate representation
 - - gtk       : Adds support for x11-libs/gtk+ (The GIMP Toolkit)
 + + lto       : Add support for link-time optimizations (unsupported,
use at
                 your own risk).
 - - mudflap   : Add support for mudflap, a pointer use checking library
 - - multislot : Allow for SLOTs to include minor version (3.3.4 instead
of
                 just 3.3)
 - - nls       : Adds Native Language Support (using gettext - GNU
locale
                 utilities)
 - - nocxx     : Old flag -- USE=cxx from now on
 - - nopie     : Disable PIE support (NOT FOR GENERAL USE)
 - - nossp     : Disable SSP support (NOT FOR GENERAL USE)
 + + nptl      : Enable support for Native POSIX Threads Library, the
new
                 threading module (requires linux-2.6 or better usually)
 - - objc      : Build support for the Objective C code language
 - - objc++    : Build support for the Objective C++ language
 - - objc-gc   : Build support for the Objective C code language Garbage
                 Collector
 - - openmp    : Build support for the OpenMP (support parallel
computing),
                 requires >=sys-devel/gcc-4.2 built with USE="openmp"
 - - test      : Workaround to pull in packages needed to run with
                 FEATURES=test. Portage-2.1.2 handles this internally,
so don't
                 set it in make.conf/package.use anymore
 - - vanilla   : Do not add extra patches which change default
behaviour; DO
                 NOT USE THIS ON A GLOBAL SCALE as the severity of the
meaning
                 changes drastically

[gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[James]

Willie Wong <wwong <at> math.princeton.edu> writes:


> > It makes gcc-4.5.3 use a newer method to detect parallelism, thus
> > (potentially) makes programs compiled by gcc to have better multithreaded
> > performance.

> Now, why can't the USE descriptions be like the kernel option
> descriptions and have something like what Pandu wrote included? 

I added this to root's  .bashrc a long time ago:

# USE flag settings hack by Ciaran McCreesh:
explainuseflag(){ sed -ne "s,^\([^ ]*:\)\?$1 - ,,p" $(portageq
portdir)/profiles/use.{,local.}desc; }
alias ef="explainuseflag"


Then simply use the alias for a quick check to learn about all the different
uses of a given flag:

'ef graphite'

# ef graphite
Enable support for non-Roman fonts via media-gfx/graphite2
Enable support for non-Roman fonts via media-gfx/graphite2
Add support for the framework for loop optimizations based on a polyhedral
intermediate representation

Then drill down into the a specific package's use flag meaning, using the
aforementioned 'equery u' delineated by Albert.

hth,

James

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Willie Wong]

On Thu, Nov 17, 2011 at 07:41:21PM +0000, James wrote:
> > Now, why can't the USE descriptions be like the kernel option
> > descriptions and have something like what Pandu wrote included? 
> 
> I added this to root's  .bashrc a long time ago:
> 
> # USE flag settings hack by Ciaran McCreesh:
> explainuseflag(){ sed -ne "s,^\([^ ]*:\)\?$1 - ,,p" $(portageq
> portdir)/profiles/use.{,local.}desc; }
> alias ef="explainuseflag"
> 
> 
> Then simply use the alias for a quick check to learn about all the different
> uses of a given flag:
> 
> 'ef graphite'
> 
> # ef graphite
> Enable support for non-Roman fonts via media-gfx/graphite2
> Enable support for non-Roman fonts via media-gfx/graphite2
> Add support for the framework for loop optimizations based on a polyhedral
> intermediate representation
> 
> Then drill down into the a specific package's use flag meaning, using the
> aforementioned 'equery u' delineated by Albert.

You people seem to miss my point. I know perfectly well how to find 
the USE descriptions. It is just that the USE description, in this 
case (as in many others) isn't terribly useful. 

"Add support for the framework for loop optimizations based on a 
polyhedral intermediate representation" means absolutely gibberish to
me.

But if one were to add an additional one or two lines a la Pandu, 
about how it is supposed to make " gcc-4.5.3 use a newer method to 
detect parallelism, thus (potentially) makes programs compiled by gcc 
to have better multithreaded performance" and perhaps even a Kernel 
help page style "It is mostly stable. If unsure, say Yes."

It would be ever so much more helpful for people who would like to
find out what new flags do before deciding whether or not to follow
the default recommended by the devs which are set into the profile.

(I'm not saying this type of hand holding is necessary for all flags:
"enable support for non-Roman fonts via media-gfx/graphite2" is 
perfectly understandable, as are most other flags about features a 
"user" is likely to interact with. But for some of the more "system" 
type flags (see also that python/perl flag business from the recent 
months), I think the USE descriptions can stand some improvement.)

W

-- 
Willie W. Wong                                     wwong@math.princeton.edu
Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire 
         et vice versa   ~~~  I. Newton

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Pandu Poluan]

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

On Nov 18, 2011 9:27 PM, "Willie Wong" <wwong@math.princeton.edu> wrote:
>
> On Thu, Nov 17, 2011 at 07:41:21PM +0000, James wrote:
> > > Now, why can't the USE descriptions be like the kernel option
> > > descriptions and have something like what Pandu wrote included?
> >
> > I added this to root's  .bashrc a long time ago:
> >
> > # USE flag settings hack by Ciaran McCreesh:
> > explainuseflag(){ sed -ne "s,^\([^ ]*:\)\?$1 - ,,p" $(portageq
> > portdir)/profiles/use.{,local.}desc; }
> > alias ef="explainuseflag"
> >
> >
> > Then simply use the alias for a quick check to learn about all the
different
> > uses of a given flag:
> >
> > 'ef graphite'
> >
> > # ef graphite
> > Enable support for non-Roman fonts via media-gfx/graphite2
> > Enable support for non-Roman fonts via media-gfx/graphite2
> > Add support for the framework for loop optimizations based on a
polyhedral
> > intermediate representation
> >
> > Then drill down into the a specific package's use flag meaning, using
the
> > aforementioned 'equery u' delineated by Albert.
>
> You people seem to miss my point. I know perfectly well how to find
> the USE descriptions. It is just that the USE description, in this
> case (as in many others) isn't terribly useful.
>
> "Add support for the framework for loop optimizations based on a
> polyhedral intermediate representation" means absolutely gibberish to
> me.
>
> But if one were to add an additional one or two lines a la Pandu,
> about how it is supposed to make " gcc-4.5.3 use a newer method to
> detect parallelism, thus (potentially) makes programs compiled by gcc
> to have better multithreaded performance" and perhaps even a Kernel
> help page style "It is mostly stable. If unsure, say Yes."
>
> It would be ever so much more helpful for people who would like to
> find out what new flags do before deciding whether or not to follow
> the default recommended by the devs which are set into the profile.
>
> (I'm not saying this type of hand holding is necessary for all flags:
> "enable support for non-Roman fonts via media-gfx/graphite2" is
> perfectly understandable, as are most other flags about features a
> "user" is likely to interact with. But for some of the more "system"
> type flags (see also that python/perl flag business from the recent
> months), I think the USE descriptions can stand some improvement.)
>

I agree with you (and not because my name is mentioned :-P).

I got lucky with USE "graphite": gcc's homepage is quite clear; a 15-minute
reading convinced me to try graphite. But there are still lots of other USE
flags that sent me on hours of goose-chase before I can enable/disable with
conviction.

I'm not sure where to put the more detailed explanations, though; perhaps a
$PN.usedesc file in the package's directory? Kind of a complement to the
.ebuild file(s).

Rgds,

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

Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?

[Michael Mol]

On Fri, Nov 18, 2011 at 9:24 AM, Willie Wong <wwong@math.princeton.edu> wrote:
> On Thu, Nov 17, 2011 at 07:41:21PM +0000, James wrote:
>> > Now, why can't the USE descriptions be like the kernel option
>> > descriptions and have something like what Pandu wrote included?
>>
>> I added this to root's  .bashrc a long time ago:
>>
>> # USE flag settings hack by Ciaran McCreesh:
>> explainuseflag(){ sed -ne "s,^\([^ ]*:\)\?$1 - ,,p" $(portageq
>> portdir)/profiles/use.{,local.}desc; }
>> alias ef="explainuseflag"
>>
>>
>> Then simply use the alias for a quick check to learn about all the different
>> uses of a given flag:
>>
>> 'ef graphite'
>>
>> # ef graphite
>> Enable support for non-Roman fonts via media-gfx/graphite2
>> Enable support for non-Roman fonts via media-gfx/graphite2
>> Add support for the framework for loop optimizations based on a polyhedral
>> intermediate representation
>>
>> Then drill down into the a specific package's use flag meaning, using the
>> aforementioned 'equery u' delineated by Albert.
>
> You people seem to miss my point. I know perfectly well how to find
> the USE descriptions. It is just that the USE description, in this
> case (as in many others) isn't terribly useful.
>
> "Add support for the framework for loop optimizations based on a
> polyhedral intermediate representation" means absolutely gibberish to
> me.
>
> But if one were to add an additional one or two lines a la Pandu,
> about how it is supposed to make " gcc-4.5.3 use a newer method to
> detect parallelism, thus (potentially) makes programs compiled by gcc
> to have better multithreaded performance"

Pretty sure having the word 'optimizations' is sufficient for that.
The rest, you can look up. (Sorry, I hate "Just google it" answers
more than most, but I think it's appropriate in this case)

IMO, USE flags should have good meaning to people familiar with the
field the package is related to. Otherwise, to keep the same terse
length, you have to "dumb it down"...but how far do you go?

Now, in this case, I think the use of the word 'polyhedral' in the
description is just silly; that's not going to mean anything to anyone
not intimately familiar with compiler optimizations, if not intimately
familiar with graphite itself. It should probably read something more
like "Add support for the experimental 'graphite' framework for loop
optimizations."

If I read his email correctly, Pandu indicated that multithreaded
environments are an example of the impact the new optimization engine
may have. I don't think he indicated that that was its specific
function, so I wouldn't go so far as to point out multithreaded
environments in the USE flag description.

> and perhaps even a Kernel
> help page style "It is mostly stable. If unsure, say Yes."

I'm pretty sure that's the purpose of the default state of USE flags;
if it's enabled by default, it's "if unsure, say Yes." If it's
disabled by default, it's "if unsure, say No."

> It would be ever so much more helpful for people who would like to
> find out what new flags do before deciding whether or not to follow
> the default recommended by the devs which are set into the profile.

Honestly, if you don't know (and I didn't), the best option seems to
me to be to ask a similar question to what Stéphane asked. Perhaps
"what does the 'graphite' USE flag for gcc add?", but go on to say, "I
see the USE flag description is '...', but what's the result?"

>
> (I'm not saying this type of hand holding is necessary for all flags:
> "enable support for non-Roman fonts via media-gfx/graphite2" is
> perfectly understandable, as are most other flags about features a
> "user" is likely to interact with. But for some of the more "system"
> type flags (see also that python/perl flag business from the recent
> months), I think the USE descriptions can stand some improvement.)

Sure. The problem is, what constitutes an improvement for each case?
(And perhaps it'd be a good idea to file bug reports against the
ebuilds.)

IIRC, the recent 'perl' USE flag kerfluffle was about removing 'perl'
support dropping tabs in an application, when those tabs were made
possible by a particular Perl script. I doubt that was the only
perl-based extension, but the argument made at the time was that the
USE flag that affected Perl support for the app should specifically
invoke that it affected that extensions.

That's like saying that a 'perl' or 'extensions' USE flag for irssi
should talk about disabling nick highlighting, when it would also
affect named windows, presence notifications...*anything* that depends
on its Perl extensions mechanism.

-- 
:wq