| 1 |
Hallo nochmal, |
| 2 |
|
| 3 |
das mögen hier vielleicht einige als überflüssig erachten, aber da Google zu |
| 4 |
dem Problem nicht sehr aussagekräftig war, und es evtl. noch andere |
| 5 |
Nappsülzen wie mich gibt, wollte ich es einfach posten: |
| 6 |
|
| 7 |
Beim letzten Update wurde der GCC auf Version 3.4.4 gebracht. Da ich auf einem |
| 8 |
meiner Rechner nun nicht so wirklich viel Platz habe, habe ich im Anschluß |
| 9 |
etwas ausgemistet und dabei, als mir auffiel, das der GCC geslottet war, den |
| 10 |
alten gleich mit entsorgt. Ich dachte mir, ein revdep-rebuild, und die |
| 11 |
Probleme mit der libstdc++, die man ja erwarten muß, werden wieder gelöst. |
| 12 |
|
| 13 |
Leider hatte ich nicht bedacht, das Python auch in C++ geschrieben ist; und |
| 14 |
emerge ist wiederum in Python geschrieben, womit sich beim revdep-rebuild die |
| 15 |
Katze in den Schwanz beißt. |
| 16 |
|
| 17 |
Nun könnt man sagen, Backup wieder rein und gut, aber warum einfach, wenns |
| 18 |
auch kompliziert geht: |
| 19 |
Python in /tmp entpackt; "cd /tmp/Python-$VERSION && ./configure && make", |
| 20 |
danach emerge in Python-Build-Order kopiert und etwas angepasst (es soll ja |
| 21 |
das "neue" Python nehmen ("/tmp/Python-$VERSION -O" statt "/usr/bin/python |
| 22 |
-O" in der ersten Zeile) und anschließend den Pfad entsprechend gesetzt |
| 23 |
(export PATH="/tmp/Python-$VERSION:$PATH"). Damit ließ sich Python sehr schon |
| 24 |
remergen und ein anschließendes revdep-rebuild läuft wieder. |
| 25 |
|
| 26 |
Ich gebe zu, ein wenig von hinten durchs Knie ins Auge, aber es |
| 27 |
funktioniert. ;) |
| 28 |
|
| 29 |
MfG Jan |
| 30 |
|
| 31 |
-- |
| 32 |
OpenPGP Public-Key Fingerprint: |
| 33 |
0E9B 4052 C661 5018 93C3 4E46 651A 7A28 4028 FF7A |
Archives