View previous topic :: View next topic |
Author |
Message |
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Fri Jan 08, 2010 12:21 pm Post subject: [gelöst] Fehler beim Linken. |
|
|
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: Code: | * 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 |
|
Back to top |
|
|
firefly Watchman
Joined: 31 Oct 2002 Posts: 5320
|
Posted: Fri Jan 08, 2010 12:28 pm Post subject: |
|
|
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. _________________ Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
Back to top |
|
|
69719 l33t
Joined: 20 Sep 2004 Posts: 865
|
Posted: Fri Jan 08, 2010 1:05 pm Post subject: |
|
|
Hast du mal dev-util/lafilefixer laufen lassen? |
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Fri Jan 08, 2010 1:12 pm Post subject: |
|
|
Ja, das liefert: Code: | /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. |
|
|
Back to top |
|
|
Josef.95 Advocate
Joined: 03 Sep 2007 Posts: 4669 Location: Germany
|
Posted: Fri Jan 08, 2010 1:13 pm Post subject: |
|
|
Hi
Ansonsten schau doch auch mal ob dir der "lafilefixer" hier weiterhilft.
Falls noch nicht installiert "emerge lafilefixer"
und dann zb ein Code: | # lafilefixer --justfixit | grep -v skipping |
Zur Sicherheit dann noch ein "revdep-rebuild" hinterher...
/edit:
Oh.., da war escor etwas flotter... |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Fri Jan 08, 2010 2:07 pm Post subject: |
|
|
Kann es sein, dass bei Dir der Link Code: | /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. |
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Fri Jan 08, 2010 2:34 pm Post subject: |
|
|
mv wrote: | Kann es sein, dass bei Dir der Link Code: | /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. | libiberty.a ist bei mir kein Link, sondern als Datei im Ordner der binutils. |
|
Back to top |
|
|
Josef.95 Advocate
Joined: 03 Sep 2007 Posts: 4669 Location: Germany
|
Posted: Fri Jan 08, 2010 2:49 pm Post subject: |
|
|
Hm.., hier auf einem x86 System ist es auch ein Link Code: | # 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 |
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Fri Jan 08, 2010 3:29 pm Post subject: |
|
|
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 bei Dir ebenfalls nicht den genannten Symlink? |
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Fri Jan 08, 2010 3:47 pm Post subject: |
|
|
Entschuldigung, falsch rum gedacht. Doch, im Ordner /usr/x86_64-pc-linux-gnu/lib/ ist libiberty als LInk auf den binutils Ordner vorhanden. |
|
Back to top |
|
|
musv Advocate
Joined: 01 Dec 2002 Posts: 3365 Location: de
|
Posted: Fri Jan 08, 2010 8:01 pm Post subject: |
|
|
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? |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Fri Jan 08, 2010 8:25 pm Post subject: |
|
|
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? |
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Fri Jan 08, 2010 8:38 pm Post subject: |
|
|
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... |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Fri Jan 08, 2010 8:39 pm Post subject: |
|
|
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 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. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Fri Jan 08, 2010 8:46 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Fri Jan 08, 2010 9:22 pm Post subject: |
|
|
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: Code: | 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.... |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Sat Jan 09, 2010 12:54 am Post subject: |
|
|
Klaus Meier wrote: | Ok, du meintest /etc/env.d/05binutils. Und da steht bei mir folgendes drin: Code: | 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. |
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:
Code: | 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... |
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Sat Jan 09, 2010 7:44 am Post subject: |
|
|
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. |
|
Back to top |
|
|
schachti Advocate
Joined: 28 Jul 2003 Posts: 3765 Location: Gifhorn, Germany
|
Posted: Sat Jan 09, 2010 7:58 am Post subject: |
|
|
Bei mir tritt übrigens das gleiche Phänomen auf, habe das System am 30.12. neu aufgesetzt... _________________ Never argue with an idiot. He brings you down to his level, then beats you with experience.
How-To: Daten verschlüsselt auf DVD speichern. |
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Sat Jan 09, 2010 8:05 am Post subject: |
|
|
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: Code: | 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 |
|
|
Back to top |
|
|
Josef.95 Advocate
Joined: 03 Sep 2007 Posts: 4669 Location: Germany
|
Posted: Sat Jan 09, 2010 4:12 pm Post subject: |
|
|
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) |
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Sat Jan 09, 2010 6:08 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|