# [gelöst] Fehler beim Linken.

## Klaus Meier

Hab aus Spaß mein KDE neu gebaut, weil ich da was ausprobieren wollte nun wollen die binutils nicht. revdep-rebuild liefert immer folgendes und ich bekomme es nicht weg:

```
* Generated new 2_ldpath.rr

 * Checking dynamic linking consistency

[ 41% ]  *   broken /usr/lib64/binutils/x86_64-pc-linux-gnu/2.20/libbfd.la (requires -liberty)

 *   broken /usr/lib64/binutils/x86_64-pc-linux-gnu/2.20/libopcodes.la (requires -liberty)

[ 100% ]

 * Generated new 3_broken.rr
```

Probleme gibt es ansonsten keine, aber ich hätte es doch gerne weg.Last edited by Klaus Meier on Fri Jan 08, 2010 8:38 pm; edited 1 time in total

----------

## firefly

da der fehler nur in den la files sind, sollte es kein problem geben. Auser beim erstellen eines Programms wird über eine dieser la files eine der beiden libs dazugelinkt.

----------

## 69719

Hast du mal dev-util/lafilefixer laufen lassen?

----------

## Klaus Meier

Ja, das liefert:

```
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.20/libbfd.la already clean, skipping update.

/usr/lib64/binutils/x86_64-pc-linux-gnu/2.20/libopcodes.la already clean, skipping update.
```

----------

## Josef.95

Hi

Ansonsten schau doch auch mal ob dir der "lafilefixer" hier weiterhilft.

Falls noch nicht installiert "emerge lafilefixer"

und dann zb ein 

```
# lafilefixer --justfixit | grep -v skipping
```

Zur Sicherheit dann noch ein "revdep-rebuild" hinterher...

/edit:

Oh.., da war escor etwas flotter...

----------

## mv

Kann es sein, dass bei Dir der Link 

```
/usr/x86_64-pc-linux-gnu/lib/libiberty.a -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.20/libiberty.a
```

 fehlt? Der müsste von binutils-config o.ä. erzeugt werden...

Edit: lafilefixer würde ich nie benutzen - das ist generell für eine schlechte Idee, wenn Du es nicht gerade extrem eilig hast. Bau lieber die betroffenen Pakete (hier: binutils) in der richtigen Reihenfolge neu.

----------

## Klaus Meier

 *mv wrote:*   

> Kann es sein, dass bei Dir der Link 
> 
> ```
> /usr/x86_64-pc-linux-gnu/lib/libiberty.a -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.20/libiberty.a
> ```
> ...

 libiberty.a ist bei mir kein Link, sondern als Datei im Ordner der binutils.

----------

## Josef.95

Hm.., hier auf einem x86 System ist es auch ein Link 

```
# ls -l /usr/i686-pc-linux-gnu/lib/libiberty.a

lrwxrwxrwx 1 root root 52 20. Okt 20:01 /usr/i686-pc-linux-gnu/lib/libiberty.a -> /usr/lib/binutils/i686-pc-linux-gnu/2.20/libiberty.a
```

----------

## mv

 *Klaus Meier wrote:*   

> libiberty.a ist bei mir kein Link, sondern als Datei im Ordner der binutils.

 

Mit anderen Worten: Du hast nur /usr/lib64/binutils/x86_64-pc-linux-gnu/2.20/libiberty.a aber nicht (nicht einmal als symbolischer Link) in einem der Directories aus /etc/ld.so.conf

Das erklärt die Fehlermeldung von revdep-rebuild, die berechtigt ist, weil Du dann gegen die libbfd tatsächlich nicht linken kannst. Erzeugt 

```
binutils-config 1
```

 bei Dir ebenfalls nicht den genannten Symlink?

----------

## Klaus Meier

Entschuldigung, falsch rum gedacht. Doch, im Ordner /usr/x86_64-pc-linux-gnu/lib/ ist libiberty als LInk auf den binutils Ordner vorhanden.

----------

## musv

 *mv wrote:*   

> Edit: lafilefixer würde ich nie benutzen - das ist generell für eine schlechte Idee, wenn Du es nicht gerade extrem eilig hast. Bau lieber die betroffenen Pakete (hier: binutils) in der richtigen Reihenfolge neu.

 

Gibt's einen Grund dafür? Ich benutz den mittlerweile nach jedem Update. 

Grund: Ich weiß nicht, ob es inzwischen mal gefixt wurde, aber jahrlang durfte ich bei jedem gcc-Update 2 la-Dateien umschreiben, in denen grundsätzlich eine Pfadangabe falsch war. Die konnte man auch 30 mal neubauen, und trotzdem war der Fehler noch vorhanden. Seit lafilefixer hab ich die Probleme nicht mehr.

Was könnte das Ding denn kaputtmachen?

----------

## mv

 *Klaus Meier wrote:*   

> Doch, im Ordner /usr/x86_64-pc-linux-gnu/lib/ ist libiberty als LInk auf den binutils Ordner vorhanden.

 

Wenn dieser Ordner in /etc/ld.so.conf aufgelistet ist, sollte revdep-rebuild keinen Grund haben, das .la-file wegen "fehlender Library" zu bemängeln (so ist es zumindest bei mir und auch in Zeile 138 von revdep-rebuild nachzulesen). Benutzt Du das aktuelle app-portage/gentoolkit-0.3.0_rc8?

----------

## Klaus Meier

 *mv wrote:*   

>  *Klaus Meier wrote:*   Doch, im Ordner /usr/x86_64-pc-linux-gnu/lib/ ist libiberty als LInk auf den binutils Ordner vorhanden. 
> 
> Wenn dieser Ordner in /etc/ld.so.conf aufgelistet ist, sollte revdep-rebuild keinen Grund haben, das .la-file wegen "fehlender Library" zu bemängeln (so ist es zumindest bei mir und auch in Zeile 138 von revdep-rebuild nachzulesen). Benutzt Du das aktuelle app-portage/gentoolkit-0.3.0_rc8?

 

Danke, das wars! Ist jetzt echt das erste Mal, dass ich ld.so.conf manuell bearbeiten musste. Na ich bin begeistert. Also diese Zeile fehlte. Und wollte auch nicht dazu, egal wie oft ich emerge binutils, eselect binutils und binutils-config gemacht habe...

----------

## mv

 *musv wrote:*   

>  *mv wrote:*   Edit: lafilefixer würde ich nie benutzen - das ist generell für eine schlechte Idee, wenn Du es nicht gerade extrem eilig hast. Bau lieber die betroffenen Pakete (hier: binutils) in der richtigen Reihenfolge neu. 
> 
> Gibt's einen Grund dafür?

 

Ja, denn es arbeitet an Portage vorbei: Die .la-Files werden auf der Festplatte umgeschrieben, ohne dass Änderungsdatum und vor allem Prüfsumme in der Portage-Datenbank aktualisiert werden (was technisch auch schwer möglich ist, solange es dazu kein Interface oder zumindest dokumentiertes Format gibt). Bei älteren Portage-Versionen hätte dies sogar dazu geführt, dass die .la-Files bei einem Upgrade oder Deinstallation des Pakets auf der Platte bleiben (bei einem Upgrade also auch dann, wenn die neue Version das File gar nicht installiert hätte). Derzeit verhält sich portage zwar anders, aber vielleicht wird das ja wieder einmal geändert, und vor allem funktionieren auch Dinge wie 

```
equery check
```

 nicht mehr, weil die Checksumme halt falsch ist.

 *Quote:*   

> jahrlang durfte ich bei jedem gcc-Update 2 la-Dateien umschreiben

 

Das ist dann entweder ein Bug im gcc, der besser gemeldet und im Ebuild ausgebaut statt "manuell" gefixt werden sollte, oder es liegt daran, dass Du vor gcc erst noch ein anderes Paket aktualisieren solltest. Ohne genauere Info kann ich dazu jetzt aber nichts sagen - bei mir gab es nie ein solches Problem. Seit -Wl,--as-needed sollten solche bösen Fälle auch deutlich geringer geworden sein.

----------

## mv

 *Klaus Meier wrote:*   

> Ist jetzt echt das erste Mal, dass ich ld.so.conf manuell bearbeiten musste. Na ich bin begeistert. Also diese Zeile fehlte. Und wollte auch nicht dazu, egal wie oft ich emerge binutils, eselect binutils und binutils-config gemacht habe...

 

Vermutlich hätte ein env-update gereicht: Nach binutils-config sollte die Datei /etc/05binutils eine Zeile der Art LDPATH=/usr/x86_64-pc-linux-gnu/lib enthalten, und env-update baut daraus dann die /etc/ld.so.conf. Warum dies nicht schon bei der Installation von binutils geschah, wird man jetzt freilich nicht mehr nachvollziehen können.

----------

## Klaus Meier

 *mv wrote:*   

>  *Klaus Meier wrote:*   Ist jetzt echt das erste Mal, dass ich ld.so.conf manuell bearbeiten musste. Na ich bin begeistert. Also diese Zeile fehlte. Und wollte auch nicht dazu, egal wie oft ich emerge binutils, eselect binutils und binutils-config gemacht habe... 
> 
> Vermutlich hätte ein env-update gereicht: Nach binutils-config sollte die Datei /etc/05binutils eine Zeile der Art LDPATH=/usr/x86_64-pc-linux-gnu/lib enthalten, und env-update baut daraus dann die /etc/ld.so.conf. Warum dies nicht schon bei der Installation von binutils geschah, wird man jetzt freilich nicht mehr nachvollziehen können.

 

Ok, du meintest /etc/env.d/05binutils. Und da steht bei mir folgendes drin:

```
MANPATH=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.20/man

INFOPATH=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.20/info
```

Wie gesagt, alles sehr mysteriös. Aber hat doch alles seine guten Seiten, mal wieder was dazu gelernt. Und: Warum geht das 50 mal gut und dann einmal nicht....

----------

## mv

 *Klaus Meier wrote:*   

> Ok, du meintest /etc/env.d/05binutils. Und da steht bei mir folgendes drin:
> 
> ```
> MANPATH=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.20/man
> 
> ...

 

In der Tat, sehr mysteriös - das kann da eigentlich gar nicht drinstehen: Der Code, der die genannte Datei erzeugt (/usr/bin/binutils-config Z.163-171), sieht nämlich so aus:

```
   if [[ ${TARGET} == ${HOST} ]] ; then

      DATAPATH=/usr/share/binutils-data/${TARGET}/${VER}

      [[ -d ${DATAPATH}/man ]] && \

      echo "MANPATH=${DATAPATH}/man" > "${ROOT}"/etc/env.d/05binutils

      [[ -d ${DATAPATH}/info ]] && \

      echo "INFOPATH=${DATAPATH}/info" >> "${ROOT}"/etc/env.d/05binutils

      # hmm, `ld` has this in SEARCH_DIR(), but ld.so does not ...

      echo "LDPATH=/usr/${TARGET}/lib" >> "${ROOT}"/etc/env.d/05binutils

   fi
```

 Insbesondere wird also - ganz unabhängig von den Pfaden, also selbst wenn TARGET falsch sein sollte, o.ä. - auf jeden Fall ein LDPATH in /etc/env.d/05binutils ausgegeben, oder andernfalls die Datei gar nicht verändert...

----------

## Klaus Meier

Ich hab das Gefühl, da ist beim stage3 von 31.12. was in die Hose gegangen. Ich hab ja noch das Backup von der Installation, werde das mal vergleichen, was da vorliegt. Durch Fehlbedienung geht das doch nicht, ich hab doch alles probiert.

----------

## schachti

Bei mir tritt übrigens das gleiche Phänomen auf, habe das System am 30.12. neu aufgesetzt...

----------

## Klaus Meier

Na dann hast ja jetzt die Lösung und dann kann man davon ausgehen, dass stage3 ne Macke hat.

Und noch etwas, ld.so.conf edditieren bring es nicht, das wird wieder rückgängig gemacht. Ich habe jetzt die 05binutils vom Backup zurückkopiert, ich hoffe, jetzt ist Ruhe. Poste sie hier noch mal:

```
MANPATH=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.20/man

INFOPATH=/usr/share/binutils-data/x86_64-pc-linux-gnu/2.20/info

LDPATH=/usr/x86_64-pc-linux-gnu/lib
```

----------

## Josef.95

 *Klaus Meier wrote:*   

> [....]dann kann man davon ausgehen, dass stage3 ne Macke hat.

 Das könnte wohl gut sein...

Das ist ja leider einer der Nachteile, der ansonsten gut funktionierenden Stage3 Autobuilds , sie sind ja kaum getestet .., können also durchaus mal ein Fehler enthalten. (hab ich aber bisher noch nicht gehabt)

Ich würde nach einer neuinstallation empfehlen nach dem ersten booten zumindest noch mal das Grundsystem via

"emerge -ave system" neuzubauen.

(So würde man auch gleich die Optimierungen (CFLAGS usw) mit nutzen)   :Wink: 

----------

## Klaus Meier

Ich hab ein emerge -e system gemacht.... Hat das Problem nicht gelöst..... Wobei in demFall ja auch ein emerge binutils hätte reichen sollen, und das hatte ich nun oft genug durch.

----------

