| 1 |
Duncan wrote: |
| 2 |
> march=k8 (aka opteron, aka athlon64, aka athlon-fx) is supposed to be a |
| 3 |
> synonym, that is, identical to march=athlon64 (and the other akas |
| 4 |
> above). However, newer gcc versions also have march=k8-sse3, which will |
| 5 |
|
| 6 |
That is interesting piece of information. Where did you get it? The gcc |
| 7 |
man page is not very informative, just listing the four names on the |
| 8 |
same row. |
| 9 |
|
| 10 |
> But what what's much more likely to be happening is that your portage is |
| 11 |
> too old to work with a newer tree and/or the newer profile the new |
| 12 |
> machine is on. That's particularly true if you were on stable, not |
| 13 |
> ~arch, as stable portage is already somewhat behind the latest features, |
| 14 |
> in addition to that year. In particular, if you have an old pre- |
| 15 |
> cascading profiles portage, it's stale indeed. If the old profile is |
| 16 |
> still around, perhaps you can update just portage, first. |
| 17 |
|
| 18 |
The old profile was 2007.0, I don't know if that was pre-cascading. |
| 19 |
|
| 20 |
The first problem I had was that portage snapshot is now compressed with |
| 21 |
lzma, which in the old system was not even installed. I managed to find |
| 22 |
a .tar.bz2 snapshot and tried to update portage as you suggest, but |
| 23 |
again was bitten by lzma (some packages ship in lzma compress format). |
| 24 |
The while trying to work around the fact that lzma was not compiling I |
| 25 |
made the linux-utils mess. |
| 26 |
|
| 27 |
> FWIW for the future, I'd suggest updating at least every six months or |
| 28 |
> so, just to keep from getting in such binds. But six-month updates are |
| 29 |
> already likely to be more difficult than necessary. Three-month updates |
| 30 |
> are the most I'd want to go on a routine basis. By a year out, indeed, |
| 31 |
> grabbing the latest stage tarball and going from there, as you discuss |
| 32 |
> below, is getting to be the most viable option. |
| 33 |
|
| 34 |
I was not so keen to frequent updates due to the long compilation time |
| 35 |
on the Sempron plus the fact that I do not have frequent access to that |
| 36 |
system. I just recently discovered the binpkg feature, I'm going to |
| 37 |
update the system more often now. |
| 38 |
|
| 39 |
> Another alternative, if you trust a specific Gentoo/amd64 user, is to ask |
| 40 |
> them to create a binpkg for you, specifying USE and CFLAGS as needed. |
| 41 |
|
| 42 |
That's not necessary, I do have other gentoo boxes working. |
| 43 |
|
| 44 |
raf |
Archives