2015-04-10 7 views
10

Ich bin es gewohnt, für Linux zu kompilieren, so dass diese .lib Zeug ist ein bisschen komisch für mich. Mit meinem Programm unter Visual Studio bekomme ich zufällige ungelöste externe Symbole für andere Bibliotheken und sogar Microsoft Laufzeiten.Random unaufgelöste externe Symbole, die nicht da sein sollten

1>glfw3.lib(init.c.obj) : error LNK2019: unresolved external symbol __imp__vsnprintf referenced in function __glfwInputError 
1>MSVCRTD.lib(vsnprintf.obj) : error LNK2001: unresolved external symbol __imp__vsnprintf 
1>glfw3.lib(context.c.obj) : error LNK2019: unresolved external symbol __imp__sscanf referenced in function _parseVersionString 
1>MSVCRTD.lib(vsnprintf.obj) : error LNK2001: unresolved external symbol __imp___vsnprintf 
1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\OLDNAMES.lib : warning LNK4272: library machine type 'UNKNOWN' conflicts with target machine type 'X86' 

ich nur mit Bibliotheken und ich kann sie bestätigen gefunden werden:

x86/glew32s.lib 
x86/glfw3.lib 
x86/glfw3dll.lib 
opengl32.lib 

Mit ihren vererbten Werte:

kernel32.lib 
user32.lib 
gdi32.lib 
winspool.lib 
comdlg32.lib 

kann ich bestätigen, dass dies die genaue Reihenfolge ist . Ich habe versucht, Windows 7 SDK und Visual Studio zu installieren und neu zu installieren - ich bin auch auf Windows 7.

Jede Hilfe in Bezug auf dieses Problem würde geschätzt werden und ich freue mich, weitere Informationen zu geben, wenn erforderlich.

Danke, Boncey

+0

Offenbar ist dies kein Problem, die Bibliotheken zu finden, aber nicht übereinstimmende Architekturen (obwohl das, was "UNKNOWN" hier tut, ein bisschen verwirrend ist ...). – JBL

+0

Keine Ahnung, ich habe keine Ahnung was OLDNAMES.lib tut und ich habe es trotzdem nicht aufgenommen. : s – Boncey

+0

@JBL Ich bin mir da nicht so sicher; Ich bekomme den gleichen Fehler mit 32-Bit-GLFW + 32-Bit-MSVCRT.lib wie mit 64-Bit-GLFW + 64-Bit MSVCRT.lib. – Dan

Antwort

7

Das Problem ist, dass Ihre GLFW statische Bibliotheken mit einer anderen Version von Visual Studio erstellt wurden als die, die Sie verwenden. Ab dem Frühjahr 2015 sind die auf glfw.org vorbereiteten nicht kompatibel mit Visual Studio 2015 RC (das Sie zu verwenden scheinen).

Glücklicherweise ist GLFW eine kleine Codebasis, die unter einer permissiven Lizenz veröffentlicht wurde. Die einfachste Lösung besteht also darin, ein neues Projekt in Ihrer Lösung zu erstellen. Die Schritte werden in etwa folgendermaßen aussehen:

  1. Erstellen Sie ein neues leeres Projekt GLFW in Ihrer Lösung.
  2. Kopieren Sie die include, deps/GL, und erstellen Sie einen Ordner src.
  3. Kopieren Sie alle Quelldateien in den Ordner src für Plattformen, die Sie unterstützen möchten. Für Windows ist dies alles mit einem win oder wgl Präfix oder kein Präfix. Sie können alle Cmake-Sachen ignorieren.
  4. Erstellen Sie eine Datei in srcglfw_config.h enthält #defines von _GLFW_WIN32, _GLFW_WGL und _GLFW_USE_OPENGL genannt. Wenn Sie mehr als nur Windows unterstützen möchten, müssen Sie die gewünschten Optionen in dieser Datei definieren. Alle Optionen sind in src/glfw_config.h.in beschrieben.
  5. Fügen Sie dem Visual Studio-Projekt alle relevanten Dateien hinzu.
  6. Legen Sie in den Projektoptionen den Konfigurationstyp auf "static lib" fest. Stellen Sie unter C/C++> Allgemein sicher, dass SDL Checks deaktiviert ist. Fügen Sie unter Preprocessor den Definitionen hinzu.
  7. Legen Sie Ihr Hauptprojekt so fest, dass es vom GLFW-Projekt abhängt (im Kontextmenü). Fügen Sie schließlich die korrekte GLFW-Bibliothek zu Ihren Linker-Abhängigkeiten hinzu. (Ich habe das Ausgabeverzeichnis für GLFW so einrichten, die richtige lib ist nur $(SolutionDir)GLFW\$(Platform)\$(Configuration)\glfw.lib.)
+0

Update 2/2017 - vs2015 Binärdateien sind jetzt auf der GLFW Website verfügbar. –

0

Es sieht aus wie es ist ein misconnect zwischen dynamischen und statischen Laufzeitbibliothek Verknüpfung. Das Präfix "__imp" auf den Symbolen bedeutet, dass Ihr Code nach etwas aus einer DLL sucht, aber die Bibliotheken, die Sie verknüpfen, erwarten wahrscheinlich statische Laufzeitbibliotheken.

Rufen Sie die Projekteigenschaftsseiten auf (unter Build-> Properties), und suchen Sie auf der linken Seite nach der Kategorie C++. Unter "Code Generation" sollte ein Eintrag namens "Runtime Library" stehen. Dies ist wahrscheinlich derzeit auf Multithread-Debug-DLL (/ MDd) festgelegt, da es so aussieht, als würden Sie im Debug-Modus kompilieren. Ändern Sie dies in Multithread-Debug (/ MTd) und kompilieren Sie alles neu. Schau, ob das jetzt funktioniert.

+3

Das hat nichts repariert. – Boncey

18

Sie können auch eine weitere Bibliothek an Ihr Linker Eingang dh legacy_stdio_definitions.lib

Zum Eigenschaften> Linkers hinzufügen> Eingabe .

Und in zusätzlichen Abhängigkeiten fügen Sie die oben genannte Bibliothek hinzu.

+1

Da es ein kleines bisschen unklar ist, was genau hinzugefügt werden soll, ist das Feld "Zusätzliche Abhängigkeiten" eine durch Semikolons getrennte Liste von Pfaden. Es scheint, dass das Anhängen von '; legacy_stdio_definitions.lib' ausreichend sein sollte. Ich weiß nicht, wo diese Datei auf der Festplatte ist, aber VS konnte es finden. – Kat

+1

Sie können dies auch in einer CPP-Datei über #pragma kommentieren Kommentar (lib, "legacy_stdio_definitions.lib") – adzm

+0

hat gut funktioniert –