Verknüpfung Windows-DLL-Dateien, statische Bibliotheken, die mit CMake ohne hand-crafting nicht aufgelöstes symbol Namen

Die Situation

Ich bin mit Visual Studio 2008 SP1 (Professional-Edition, die sowohl für 32-bit und 64-bit
baut). Ich Suche eine Abhilfe für das, was ich glaube, ist ein sehr
wenig hilfreich "Einschränkung" in Visual Studio.

Ich finde es ziemlich
verwunderlich, dass die Visual Studio linker und compiler nicht tut, dieses Recht auf DLL-Datei
Zeitpunkt der Erstellung, um automatisch einen scan alle angegebenen statischen Bibliotheken
für alle exportierten Symbole in der gleichen Art und Weise gegeben, in Aufbau eines
Import-und Export-Datei-Bibliothek und in ein StackOverflow
Kommentar. Ich bestätigte, dass es nicht reicht, einfach anzuwenden
__declspec(dllexport) und __declspec(dllimport) Attribute
Klassen -, Funktions -, und Daten-Deklarationen in den Dateien, aus denen die
statische Bibliotheken.

Den linker scan nicht alle statischen Bibliotheken
für exportierte Symbole und so nicht ziehen Sie in die DLL-Datei (die Symbole
haben, verwiesen werden, die durch .obj Dateien, die auf der DLL-link-Kommando-Zeile oder
durch andere Mittel, die ich unten zeigen). Ohne explizite Verweise auf jede
exportierte symbol, die DLL-Datei immer noch angelegt werden, aber Ihr Zusammenhang
import-Bibliothek-Datei wird nicht erstellt.

Von dem, was ich sammeln können, empfiehlt Microsoft den Benutzern mit LIB.EXE
zum erstellen der DEF - Datei, aber leider, die LIB.EXE Seite
gilt eine Einschränkung:

Beachten Sie, dass wenn Sie erstellen Sie Ihre Bibliothek importieren in eine erste Schritt
bevor Sie Ihre .dll, müssen Sie passieren die gleiche Reihe von Objekt-Dateien
beim Bau der .dll, wie Sie übergeben, wenn der Bau der import
Bibliothek.

Dass ist eine unglückliche Einschränkung gegeben, dass ich mich auch mit CMake in
meine neue build-Umgebung. CMake blendet die details von dem, was eigentlich
an den linker übergeben (und ich finde, dass es eine gute Sache in 99% der
Zeit), aber in diesem Fall, ich brauche, um Zugang zu einigen Informationen auf
CMake Ausführungszeit, danach nicht mit der hand gemachte scripts oder
andere zerbrechliche skulduggery.

Die Fragen:

Wie kann ich das erzwingen der DLL-linker
beheben Sie alle exportierten Symbole in allen statischen Bibliotheken, aus denen die
DLL-Datei, die nicht geht, zu führen zerbrechlichkeit und zusätzliche bauen
Logik Wartung Aufgaben? Denken in Bezug auf die voll-Automatisierung hier, und
halten Sie im Verstand, ich brauche zu tun diese mehrere Male
verschiedenen DLL.

Meine Fragen sind:

1. Wie bekomme ich die set-object-Dateien und statische Bibliotheken verwendet
   auf der letzten DLL-link-Befehlszeile mithilfe von CMake syntax allein?

2. Wird die Reihenfolge der aufgelisteten Dateien auf LIB.EXE Linie (die man verwendet
   zum generieren der DEF - Datei) muss exakt übereinstimmen, die verwendet, um auf
   die DLL-link-Zeile?

3. Gibt es andere Schwierigkeiten, ich kann auch aus der Verwendung
   der LIB.EXE Ansatz zum generieren der DEF Datei?

4. Gibt es einen besseren Weg zu gehen, was diese nicht benötigen
   das aufrufen eines separaten Programms, wie LIB.EXE, vor Aufruf der
   letzten link? Ich bin besorgt über die zusätzlichen build-Aufwand jenseits der
   link selbst für LIB.EXE Scannen Sie alle der statische Bibliotheken
   wieder obwohl es gerade schrieb Sie in gesonderten Ausführungen.

Die Nicht-Antworten:

Im folgenden sind die Lösungen, die ich nicht berücksichtigen können jetzt:

1. Manuelles angeben der nicht referenzierte Symbole, die irgendwo auf anderen als
   in der ursprünglichen .h oder .cpp - Dateien, wie zu tun, dass wird
   brechen jedes mal, wenn ein Entwickler vergisst, die Datei zu aktualisieren, die Listen
   die (womöglich name-Mangling) symbol-name. Und es wird brechen
   mit nicht-user-freundlich-linker-Fehlern über nicht aufgelöste Symbole
   das wird teuer für Entwickler zum Debuggen. Diese nicht-Antwort
   umfasst die folgenden Ansätze:

   1. Explizit Hinzugefügt .obj Dateien in der DLL-link-Kommando-Zeile
      (Varianten dieser gehören das hinzufügen von "fake" .obj Dateien
      dummy Verweise auf die ansonsten nicht referenzierte, aber exportiert
      Symbole (und beachten Sie, dass dies ist, was meine alte build-Umgebung
      heute, und es stinkt) und,

   2. Handarbeit DEF Dateien die nicht referenzierte, aber
      exportiert Symbole, und,

   3. Linker-command-line-Optionen, die speziell zu verweisen, die
      nicht referenzierte, aber die exportierten Symbole.

2. Stoppen Sie die Verwendung statischer Bibliotheken insgesamt. Ich kann das nicht in der
   kurzfristig, da es zu viel von einem Strukturwandel aus den alten
   build-Umgebung bin ich Weg von. Es ist sehr wahrscheinlich werde ich
   diesen Weg in die Zukunft, nachdem alle Reste der alten bauen,
   Umgebung sind in den "Papierkorb", aber das ist nicht mein Fokus hier.

Referenz material:

• Exportieren aus einer DLL Mithilfe von DEF-Dateien
• Modul-Definition (.def) Dateien
• PRB: Kann nicht den Export von Statischen Bibliotheken w/_declspec(dllexport)
• dumpbin.exe Symbole /option
• lib.exe Optionen
• Aufbau einer Bibliothek Importieren und Exportieren, die Datei
• CMake LINK_FLAGS target-Eigenschaft