Änderungen in gcc 4.5 in Bezug auf die Verknüpfung eingeführt?

8

Ich habe ein Projekt, das eine gemeinsam genutzte Bibliothek erstellt, die mit einer anderen, ebenfalls gemeinsam genutzten Bibliothek verknüpft ist.

Wenn ich es mit gcc 4.4 kompiliere und verlinke, funktioniert alles:

  1. keine Kompilierungszeitwarnung oder Fehler,
  2. keine Verbindungszeitwarnung oder -fehler und
  3. ldd libmyproject.so meldet die Abhängigkeit korrekt mit der anderen gemeinsam genutzten Bibliothek.

Wenn ich es mit gcc 4.5 kompiliere und verknüpfe (mit genau den gleichen Flags), habe ich die folgenden Symptome:

  1. keine Kompilierungszeitwarnung oder Fehler,
  2. keine Verbindungszeitwarnung oder -fehler , aber
  3. die library ist nicht korrekt mit der anderen shared lib verknüpft: dies manifestiert sich selbst, wenn ich ldd laufe und die Verbindung nicht sehe, und auch wenn ich versuche, sie zu benutzen: während sie mit gcc 4.4 zusammenarbeitet, stürzt sie ab zur Laufzeit mit gcc 4.5 mit einem "Symbol nicht gefunden" Fehler (natürlich von der anderen lib).

Ich habe mir die Versionshinweise angesehen und meine Intuition ist, dass es etwas mit dem Neuen zu tun hat Link-Zeit-Optimierung, aber ich konnte sie nicht in genügend Details verstehen.

Hat jemand auf eine ähnliche Situation gestoßen und / oder hat er einen Ratschlag anzubieten?

(Beachten Sie, dass Ergebnisse mit 4.6 identisch mit 4.5 sind).

    
Philippe 07.11.2011, 20:49
quelle

3 Antworten

2

Um Mat's Antwort von GCC 4.5 zusammenzufassen vs 4.4 Verknüpfung mit Abhängigkeiten und die Diskussion in den Kommentaren, müssen Sie verknüpfen mit:

%Vor%     
cha0site 11.01.2012, 07:56
quelle
2

Sie können Ihre dynamisch verknüpfte Anwendung mit der Umgebungsvariablen LD_DEBUG debuggen. Dies ist eine Option von ld-linux.so.2 ; ldd ist ein Skript, um diese Option zu setzen. Alle Optionen sind auf der Manpage Ссылка beschrieben.

Wie benutzt man LD_DEBUG (in bash; der einfachste Weg):

%Vor%

Dadurch wird das Debuggen von ld-linux.so.2 - dem dynamischen Laufzeit-Linker - aktiviert. Es wird viel Debugging auf stdout oder stderr gedruckt und Sie können

  • 1) Vergleiche die Ausgabe von " LD_DEBUG=all ./your_program_4.4 " und " LD_DEBUG=all ./your_program_4.5 "
  • 2) Sehen Sie die letzten Symbole, die aufgelöst werden sollen, und suchen Sie ein fehlerhaftes Symbol.

Auch sollten Sie uns mehr Informationen geben:

  • 0) Was ist Ihr Betriebssystem und CPU-Typ? (Zeige uns die Ausgabe von uname -a ) Was ist die Version von libc? (Lauf in bash for a in /lib*/libc.so.*;do echo $a; $a; done )
  • 1) Was sind Kompilierungsflags Ihrer Bibliothek?
  • 2) Was ist der genaue Fehler, wenn Sie versuchen, die Anwendung auszuführen?
  • 3) Letzte Zeilen aus der Ausgabe von LD_DEBUG können wertvolle Informationen enthalten

UPDATE: Gute und genaue Antwort ist hier: GCC 4.5 vs 4.4 Verknüpfung mit Abhängigkeiten (von Mat)

    
osgx 07.11.2011 23:30
quelle
1

Stellen Sie sicher, dass Sie Ihre gemeinsam genutzten Bibliotheken nach Ihren Objekt- (oder Quell-) Dateien in der Linker-Befehlszeile angeben.

So mussten Sie es früher mit statischen Bibliotheken tun. Es scheint, mit neuen Versionen von GCC wieder vorteilhaft zu sein. Soweit ich das beurteilen kann, ignoriert es beim Durchsuchen einer gemeinsam genutzten Bibliothek, die keine nützlichen Symbole liefert, die gesamte Bibliothek, wodurch die Anzahl der zur Laufzeit geladenen gemeinsam genutzten Bibliotheken optimiert wird, aber die Optionen -libname angezeigt werden müssen nach den Objektdateien.

    
Jonathan Leffler 11.01.2012 08:03
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Horizontale und vertikale Zentrierung über einer sticky footer in CSS