On Sunday 18 April 2010 19:37:40 Tanstaafl wrote:
> On 2010-04-18 1:05 PM, Alan McKinnon wrote:
> > On Sunday 18 April 2010 17:38:19 Tanstaafl wrote:
> >> I must be missing something obvious...
> >>
> >> When updating gcc, and thus emerging -e both system and world
> >
> > Why are you doing that?
>
> Because it wasn't a minor bugfix update? I'm going from 4.1.2 to 4.3.4.
So what?
Is there an ABI change between 4.1.2 to 4.3.4 that causes apps built with
4.1.2 to break on 4.3.4?
> > > Have you verified that you have in fact updated gcc from one version
> > to another with an incompatible ABI?
>
> Since the GCC upgrade guide doesn't mention a way to do this, no, I
> haven't... so how does one verify this, Obi-Wan? ;)
Understand what the gcc upgrade guide is:
a quick simple guide for user who don't know tool chains inside out, that give
the minimal sequence of commands that is GUARANTEED to NOT leave the user in
the lurch. It's not the minimum possible sequence of commands to do the
upgrade, because most users don't know how to tell the difference. Here's the
logic:
"If we imply that you should merge -e world with a gcc upgrade, my inbox will
not fill with bugs from users who don't know the inner guts of the toolchain".
The Guide is not the best possible guide that can be. It is the guide that
causes the least support questions from users.
> > There is a false idea floating about that gcc updates require
> > updating -e world.
> >
> > This is not true.
>
> I've heard this before, but could never get a definitive answer on how
> to know for sure when you do and don't need to...
When the gcc devs release a new version, they will announce that there is an
ABI break, and what it applies to. It doesn't happen often, but when it does,
the gentoo maintainer ought to put a note in the ebuild.
They are quite diligent about this, much like the KDE/Qt devs do the same
thing when Nokia breaks Qt compatibility.
> >> where are the info/warn/errors logged? I see a whole bunch of
> >> separate/individual logs ion /var/log/portage/elog, but what I'm
> >> looking for is a single, easily readable log of all of the result
> >> info/warn/errors for each package.
> >
> > Configure it in /etc/make.conf, mine looks like so:
> >
> > PORT_LOGDIR=/var/log/portage
> > PORTAGE_ELOG_CLASSES="warn error log qa"
> > PORTAGE_ELOG_SYSTEM="save"
>
> I have the last two, but didn't have the first - just added it...
I think that's the default. I have it just to be explicit.
>
> So, does adding the first entry provide an overall emerge.log with just
> all of the messages in it that I can review?
>
> > Adapt to you own needs.
> >
> > If you don't have this configured, then the logs are not stored. To
> > see them again, read the ebuilds or re-run emrge
>
> Like I said, I have a bunch of *individual* logs (for individual
> ebuilds)... I was hoping for something a little easier to manage/read,
> all in one file...
for I in $(ls -1rt /path/to/emerge/logs/*) ; do cat ${I} >> some_log_file ;
done
--
alan dot mckinnon at gmail dot com
