| 1 |
On Sunday 18 April 2010 19:37:40 Tanstaafl wrote: |
| 2 |
> On 2010-04-18 1:05 PM, Alan McKinnon wrote: |
| 3 |
> > On Sunday 18 April 2010 17:38:19 Tanstaafl wrote: |
| 4 |
> >> I must be missing something obvious... |
| 5 |
> >> |
| 6 |
> >> When updating gcc, and thus emerging -e both system and world |
| 7 |
> > |
| 8 |
> > Why are you doing that? |
| 9 |
> |
| 10 |
> Because it wasn't a minor bugfix update? I'm going from 4.1.2 to 4.3.4. |
| 11 |
|
| 12 |
So what? |
| 13 |
|
| 14 |
Is there an ABI change between 4.1.2 to 4.3.4 that causes apps built with |
| 15 |
4.1.2 to break on 4.3.4? |
| 16 |
|
| 17 |
> > > Have you verified that you have in fact updated gcc from one version |
| 18 |
> > to another with an incompatible ABI? |
| 19 |
> |
| 20 |
> Since the GCC upgrade guide doesn't mention a way to do this, no, I |
| 21 |
> haven't... so how does one verify this, Obi-Wan? ;) |
| 22 |
|
| 23 |
Understand what the gcc upgrade guide is: |
| 24 |
|
| 25 |
a quick simple guide for user who don't know tool chains inside out, that give |
| 26 |
the minimal sequence of commands that is GUARANTEED to NOT leave the user in |
| 27 |
the lurch. It's not the minimum possible sequence of commands to do the |
| 28 |
upgrade, because most users don't know how to tell the difference. Here's the |
| 29 |
logic: |
| 30 |
|
| 31 |
"If we imply that you should merge -e world with a gcc upgrade, my inbox will |
| 32 |
not fill with bugs from users who don't know the inner guts of the toolchain". |
| 33 |
|
| 34 |
The Guide is not the best possible guide that can be. It is the guide that |
| 35 |
causes the least support questions from users. |
| 36 |
|
| 37 |
> > There is a false idea floating about that gcc updates require |
| 38 |
> > updating -e world. |
| 39 |
> > |
| 40 |
> > This is not true. |
| 41 |
> |
| 42 |
> I've heard this before, but could never get a definitive answer on how |
| 43 |
> to know for sure when you do and don't need to... |
| 44 |
|
| 45 |
When the gcc devs release a new version, they will announce that there is an |
| 46 |
ABI break, and what it applies to. It doesn't happen often, but when it does, |
| 47 |
the gentoo maintainer ought to put a note in the ebuild. |
| 48 |
|
| 49 |
They are quite diligent about this, much like the KDE/Qt devs do the same |
| 50 |
thing when Nokia breaks Qt compatibility. |
| 51 |
|
| 52 |
> >> where are the info/warn/errors logged? I see a whole bunch of |
| 53 |
> >> separate/individual logs ion /var/log/portage/elog, but what I'm |
| 54 |
> >> looking for is a single, easily readable log of all of the result |
| 55 |
> >> info/warn/errors for each package. |
| 56 |
> > |
| 57 |
> > Configure it in /etc/make.conf, mine looks like so: |
| 58 |
> > |
| 59 |
> > PORT_LOGDIR=/var/log/portage |
| 60 |
> > PORTAGE_ELOG_CLASSES="warn error log qa" |
| 61 |
> > PORTAGE_ELOG_SYSTEM="save" |
| 62 |
> |
| 63 |
> I have the last two, but didn't have the first - just added it... |
| 64 |
|
| 65 |
I think that's the default. I have it just to be explicit. |
| 66 |
|
| 67 |
> |
| 68 |
> So, does adding the first entry provide an overall emerge.log with just |
| 69 |
> all of the messages in it that I can review? |
| 70 |
> |
| 71 |
> > Adapt to you own needs. |
| 72 |
> > |
| 73 |
> > If you don't have this configured, then the logs are not stored. To |
| 74 |
> > see them again, read the ebuilds or re-run emrge |
| 75 |
> |
| 76 |
> Like I said, I have a bunch of *individual* logs (for individual |
| 77 |
> ebuilds)... I was hoping for something a little easier to manage/read, |
| 78 |
> all in one file... |
| 79 |
|
| 80 |
for I in $(ls -1rt /path/to/emerge/logs/*) ; do cat ${I} >> some_log_file ; |
| 81 |
done |
| 82 |
|
| 83 |
-- |
| 84 |
alan dot mckinnon at gmail dot com |
Archives