Ich versuche, von einer gemeinsam genutzten Bibliothek, die mit -fno-rtti kompiliert wurde, eine Unterklasse zu erstellen. Leider benötigen andere Bibliotheken in meiner Codebasis -frtti. Als Ergebnis bekomme ich Linkfehler, weil die Oberklasse keine typeinfo-Struktur hat.
Fehler bei einer normalen Kompilierung:
%Vor%Die Klasse, die ich ableiten möchte, ist eine android-Klasse in libsysutils (für Platz etwas gekürzt):
%Vor%Mein Stub sieht so aus:
%Vor%Alle Methoden in MyClass sind implementiert (als leere Stubs)
Ich kann die gemeinsam genutzte Bibliothek -frtti nicht kompilieren. Gibt es eine Möglichkeit, dies zu umgehen?
1) Für einfache Fälle könnten Sie einfach einen C-Wrapper der Schnittstelle (ohne RTTI) erstellen. Dann können Sie die C-Schnittstelle in RTTI-fähigen Programmen verwenden, vorausgesetzt Sie behandeln sie als abstrakte C-Typen von Ihrem RTTI-fähigen Programm.
2) Das Kompilieren der Bibliothek mit RTTI ist genau das, was Sie tun sollten (oder eine Anfrage des Anbieters), außer es gibt einen sehr guten Grund, RTTI zu deaktivieren (zB arbeiten Sie in Eine Domäne, in der Ausnahmen nicht verwendet werden sollten, z. B. ein Kernel, Treiber oder eine andere Zone ohne Ausnahme - oder Bereiche, in denen der Speicher knapp ist.
3) Ändern Sie Ihre Bibliothek so, dass sie dynamic_cast, Ausnahmen, den Typid-Operator oder was auch immer verwendet, das das Problem verursacht, und den Neuaufbau mit deaktivierter RTTI nicht verwendet. Ähnlich wie bei 1 können Sie eine separate Abstraktionsbibliothek erstellen, je nachdem, wie das Programm organisiert ist.
4a) Die nächste Option besteht darin, niemals auf die Typinformationen für das Objekt zu verweisen (z. B. nicht dynamic_cast oder throw) - und das kann ein Schmerz sein. Das wird Linkfehler von referenzierten Typeninfos entfernen.
4b) Es kann am einfachsten sein, eine innere Klasse zu erstellen (angenommen, es gibt Methoden, die Sie außer Kraft setzen müssen, und es gibt Typen, die Sie mit Ihren rtti-abhängigen Programmen verbinden müssen). Sie können einen Typ ( inner ) erstellen, der von seinem Lib-Typ erbt und die notwendigen Überschreibungen ausführt, aber dann durch eine andere Klassenhierarchie zurück aufruft (die andere Hierarchie ist frei, um rtti zu verwenden). Nun werden die virtuellen Exporte der inner -Klasse in eine TU mit rtti deaktiviert platziert (weil sie ansonsten implizit auf die Typ-Info der Basisklasse verweist). Dann können Sie die Typ-Info-Abhängigkeit einfach unter Quarantäne stellen und eine Hierarchie aufbauen, die Dinge wie Ausnahmen verwendet - diese Hierarchie verwendet den Typ inner als Wert. Natürlich, wenn das funktioniert, ist alles implementiert - Sie müssten verstehen, wie RTTI und vtables für Ihre Zielplattformen strukturiert sind (siehe ABI-Referenzen). Selbst das Weglassen von RTTI ist eine Abweichung vom Standard C ++. Es gibt keine Informationen, die besagen, dass das Vorhandensein eines Symbols zu einer ordnungsgemäßen Konstruktion Ihrer VTables und Typinformationen einer Basis führt, die ohne diese Features kompiliert wurde.
Das heißt, 1 und 2 sind Ihre sicheren Optionen, 3 ist innerhalb der Domäne der No-RTTI-Plattform-Erweiterung (sicher) und 4 ist ein Ansatz, der frei ist, auf keinem oder nur auf einigen Systemen zu arbeiten.
>Veranschaulicht 4b
%Vor% Durch die Weitergabe von -fno-rtti werden nur die Funktionen dynamic_cast und typeid gemäß der Dokumentation von gcc deaktiviert. Sie sollten in der Lage sein, Klassen abzuleiten und virtuelle Methoden ohne Probleme zu verwenden.
Der undefined reference to typeinfo for class Fehler wird normalerweise angezeigt, wenn Sie eine Funktion als virtual deklarieren, ohne eine Definition dafür anzugeben.
Tatsächlich sehe ich NetlinkHandler.h und NetlinkHandler.cpp in der AOSP tun genau das, was Sie versuchen zu tun, und ich finde keine Unterschied zwischen diesen Dateien und den Code-Snippets, die Sie gepostet haben.