# revdep-rebuild findet stets broken files in gcc Verzeichnis

## Randy Andy

Hi Leute,

würde mein System gern mal konsistent bekommen, nur leider gelingt das nicht denn:

revdep rebuild findet nach jedem Durchlauf die gleichen gebrochenen Dateien, remerged gcc (das dauert selbst mir zu lange, da ich das schon etliche male habe durchlaufen lassen.

Der Fehler lautet:

```

No outdated packages were found on your system.

 * Messages for package sys-devel/gcc-4.2.3:

 * If you have issues with packages unable to locate libstdc++.la,

 * then try running 'fix_libtool_files.sh' on the old gcc versions.

 * GNU info directory index is up-to-date.

 *

 * Portage could not find any version of the following packages it could build:

 *

 *

 * (Perhaps they are masked, blocked, or removed from portage.)

 * Try to emerge them manually.

 *

 * Build finished correctly. Removing temporary files...

 *

 * You can re-run revdep-rebuild to verify that all libraries and binaries

 * are fixed. If some inconsistency remains, it can be orphaned file, deep

 * dependency, binary package or specially evaluated library.

 * Found some broken files that weren't associated with known packages

 * The broken files are:

 *   /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.3/libgij.la

```

Ne Idee wie man das fixed? (und mein Dank wird euch ewig nachlaufen:-)

----------

## 69719

Was es schon gibt findet man hier.

Aber vielleicht hilft dir das auch weiter.

----------

## Josef.95

Hallo Randy Andy

Das schaut nach einem nicht korrekt durchgeführten gcc Update aus.

Hier solltest du alle Infos finden um das wieder in Ordnung zu bringen.

http://www.gentoo.org/doc/de/gcc-upgrading.xml

MfG

josef.95

----------

## mv

 *Josef.95 wrote:*   

> Das schaut nach einem nicht korrekt durchgeführten gcc Update aus.

 

Ja, aber nicht RandyAndy hat etwas nicht korrekt durchgeführt, sondern die Politik, bei einem gcc-removal das fatale fixlafiles-Script zu starten, ist schuld, weshalb dann die .la-Files von Portage später nicht entfernt werden.

RandyAndy, lösch' einfach /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.3/libgij.la und gut is'.

----------

## Josef.95

@mv

Wenn das funkt, habe ich wieder etwas dazugelernt  :Idea: 

PS:

Ich wollte Randy Andy auch nicht beschuldigen das Update nicht korrekt durchgeführt zu haben.

MfG

----------

## gimpel

Da hast du wohl gcc mit USE="gcj".

Im Prinzip kannst du das .la file mit einem Editor bearbeiten, und den Pfad da händisch korrigieren.

Wenn du es einfach löschst, dann machts auch absolut garkeinen Sinn gcc mit USE="gcj" zu kompilieren o.O

----------

## Josef.95

Also ich denke nach wie vor, das es an einem nicht korrekt durch geführtem gcc Update liegt.

Er hat ja den Stabilen Zweig verlassen, er verwendet die testing Version sys-devel/gcc-4.2.3

Dieses Update bedarf ja eine Manuelle Konfiguration, wird also nicht Automatisch vollzogen, die Fehlermeldung beschreibt ja schon

 *Quote:*   

> running 'fix_libtool_files.sh' on the old gcc versions

 und genau dies ist doch notwendig beim Upgrade auf die Version (4.2.3) die er ja verwendet.

Wie dies genau gemacht wird ist ja in dem Link aus meinen vorigem Post beschrieben.

@Randy Andy

Poste doch sonst bitte auch mal die Ausgabe von:

```
gcc-config -l
```

MfG

josef.95

----------

## mv

 *Josef.95 wrote:*   

> Er hat ja den Stabilen Zweig verlassen, er verwendet die testing Version sys-devel/gcc-4.2.3

 

Das hat damit nichts zu tun. Das buggy fix_libtool_files.sh gibt es in praktisch allen gcc-Versionen, und es wird beim Löschen einer alten Version leider immer ausgeführt.

Das .la-File zu fixen ist vollkommen sinnfrei, weil es ja zu keinem Paket gehört: Es hätte gelöscht werden sollen, wurde es aber nicht, weil es wegen eines irgendwann mal ausgeführten fix_libtool_files.sh verändert wurde.

----------

## gimpel

 *mv wrote:*   

> Das .la-File zu fixen ist vollkommen sinnfrei, weil es ja zu keinem Paket gehört: Es hätte gelöscht werden sollen, wurde es aber nicht, weil es wegen eines irgendwann mal ausgeführten fix_libtool_files.sh verändert wurde.

 

D'oh, hätte ich die Ausgabe von revdep-rebuild mal genau gelesen, wäre gleich klar gewesen, dass du recht hast.

----------

## Josef.95

@mv

Sorry, du wirst wahrscheinlich recht haben.

Ich halte hiezu lieber erst mal meinen Mund, denn so tief stecke ich dann doch noch nicht in der Materie  :Embarassed: 

MfG

josef.95

----------

## Randy Andy

Hallo escor,

ist ja nicht so als hätte ich nicht schon 1/2 Tag mit Suchen verbracht, trotzdem nochmals Dank für den Link auf die Suchfunktion   :Wink: 

Hab vermutlich mal wieder schlechte Suchkriterien verwendet, die mich allesamt auf ältere gcc Vers. leitetete, oder mir weismachen wollten dass es sich da um einen gcc Bug handeln sollte.

Die Anweisungen aus deinem zweiten Link hab ich abgearbeitet, haben jedoch nichts an der Problematig geändert.

Dank auch an den Rest der Truppe, die sich so lebhaft beteiligt.

Tatsächlich hat das Entfernen des gjcFlags und ein anschließendes revdep-rebuild (remerge gcc) das Problem beseitigt!   :Very Happy: 

Übrig gelieben ist allerdings noch eine gebrochene Abhängigkeit, und die kriegen wir doch auch noch hin, oder? 's wär schon toll wenn ihr mir noch ein bisi unter die Arme greift.

Also, revdep-rebuild meldet noch:

 Checking dynamic linking consistency

[ 26% ]  *   broken /usr/kde/3.5/lib32/libqtmcop.so.1.0.0 (requires libqt-mt.so.3)

darauf hin remerged es:

Emerging (1 of 1) app-emulation/emul-linux-x86-soundlibs-20080418

was auch problemlos klappt, jedoch immer wieder nach jedem rev-reb lauf mit obiger Fehlermeldung.

Darauf hin hab ich ein emerge -C emul-linux-x86-soundlibs gemacht, und es anschließend wieder gemerged.

Dann wieder ein rev-reb Durchlauf - das Gleiche.

Wie geht man denn nun systematisch weiter, z.B. woher weiss man zu welchem Paket libqtmcop.so gehört,

soll ich die Datei enfach mal löschen, oder wie geh ich da am geschicktesten vor.

Dank Dank, 1000 Dank.

----------

## mv

 *Randy Andy wrote:*   

> emul-linux-x86-soundlibs

 

Die ganzen emul-linux-x86-*-Pakete subd nur in Binärform vorhanden, also wird re-emergen immer exakt die selben Files erzeugen.

Eigentlich müssten alle davon benutzten libraries ebenfalls in einem der emul-linux-x86-* Pakete vorhanden sein. Vielleicht eine fehlende Dependency bzgl. emul-linux-x86-qt. Ist Letzteres installiert?

Ich bin allerdings auch über den Ort des Files erstaunt: Die emul-linux-x86-*-Pakete installieren normalerweise nur in /usr/lib32/*

(aber ich benutze für diese Pakete grundsätzlich ~amd64 und will jetzt nicht nur zum Testen eine ältere Version downloaden).

----------

## furanku

Wenn ich mich recht erinnere hört der re-emergen der emul-linux-x86-soundlibs auf, wenn Du diese mit USE=-arts installierst

----------

## Randy Andy

Denn man to, furanku!!!

Respekt, deine Erinnerung täuschte dich nicht.

Hat genau so funktioniert, und mein System ist nun das erste mal seit Neuinstallation konsistent - herrlich!

Darauf kann ich nun in Ruhe aufbauen und mich weiteren Problemlösungen widmen:

Versäumt daher nicht meinen nächsten Post, er kommt bestimmt  :Smile: 

Danke vorerst, bis denne.

----------

## furanku

 *Randy Andy wrote:*   

> Denn man to, furanku!!!

  Bin eigentlich nur zugezogen und gebürtiger Hesse.

 *Randy Andy wrote:*   

> Hat genau so funktioniert, und mein System ist nun das erste mal seit Neuinstallation konsistent - herrlich!
> 
> Darauf kann ich nun in Ruhe aufbauen und mich weiteren Problemlösungen widmen:
> 
> 

  Schön, daß wir Dir helfen konnten. Ohne Deine Freude zu sehr zu dämpfen: Eigentlich hast Du nur zwei unschöne Workarounds für lange bekannte Bugs angewendet. Viel schöner wäre es wenn die Bugs gefixt werden würden (ohne undankbar den Entwicklern gegenüber klingen zu wollen). Das System war vorher genauso "sauber" wie es jetzt ist und viele lassen diese "Fehler" einfach drauf, wenn man weiß daß die Ausgabe von revdep-rebuild harmlos ist.

Bis zum nächsten mal!

----------

