Verwirrt durch ungelöste externe Symbolfehler

Question

Ich versuche, eine Wrapper-Bibliothek mit VC ++ 's-Compiler zu bauen.

ErlDriver.c

#define __WIN32__
#define DLL_EXPORT __declspec(dllexport)

#include "erl_driver.h"

DLL_EXPORT int _driver_output(ErlDrvPort port, char *buf, int len) {
    return driver_output(port, buf, len);
}

build.bat

cl /I%ERL_DRIVER_H% /LD /MD ErlDriver.c

Wenn ich dies zu bauen versuchen, ich die folgenden Linker Fehler:

  

ErlDriver.obj: Fehler LNK2019: nicht aufgelöstes externes Symbol _WinDynDriverCallbacks in Funktion verwiesen __driver_output

erl_win_dyn_driver.h (im erl_driver.h )

typedef struct {
    WDD_FTYPE(driver_output) *driver_output;
    // a ton more of those
} TWinDynDriverCallbacks;

extern TWinDynDriverCallbacks WinDynDriverCallbacks;

#define driver_output (WinDynDriverCallbacks.driver_output)

So, wie Sie sehen können, WinDynDriverCallbacks ist definiert erklärt.

Was verursacht die Linker Fehler werden könnte, dann?

Answer 1

Es gibt einen feinen Unterschied zwischen etwas und „definiert,“ es in C oder C „erklärt“ ++. Wenn Sie es erklären, teilt es den Compiler, dass ein bestimmtes Symbol irgendwo anders definiert werden - das ist der Code erlauben kann, dieses Symbol zu verwenden, ohne dass die eigentliche Definition zu sehen. Sie haben noch das Symbol irgendwo im Code zu definieren, die in verknüpft ist, sonst werden Sie die Fehlermeldung erhalten Sie sehen.

Zum Beispiel ist dies eine Erklärung des Symbol WinDynDriverCallbacks:

extern TWinDynDriverCallbacks WinDynDriverCallbacks;

Der Code hat diese Erklärung -. Es ermöglicht den Code, den das Symbol, um erfolgreich zu kompilieren verwendet (aber nicht link)

Sie brauchen eine Definition irgendwo hinzuzufügen:

TWinDynDriverCallbacks WinDynDriverCallbacks;

Die Definition in eine Quellcodedatei irgendwo gehen muß (nicht im Allgemeinen in einer Header-Datei). Dies teilt den Compiler für diesen Objektraum in dem Objektcode zuzuordnen und ermöglicht das Programm Link erfolgreich.

Answer 2

Nein, es ist nicht definiert (zumindest in dem, was Sie zitiert). Es wird erklärt. Der „extern“ keyword bedeutet „die Definition für dieses Symbol erscheint in einer anderen Übersetzungseinheit (Quelldatei).“ Sie müssen sich mit der Objektdatei (oder Bibliothek) zu verknüpfen aus Kompilieren der Quelldatei erzeugt, die definiert, dass Symbol.

Answer 3

Ich habe ein sehr ähnliches Problem eine NIF auf Windows zu bauen. Nicht aufgelöstes externes Symbol _WinDynNifCallbacks. Stellt sich heraus, dies wird durch die ERL_NIF_INIT Makro definiert und in meinem Fall das gesamte Makro benötigt in einem externen C-Block eingeschlossen werden.

dh diese fehlgeschlagen

extern "C" ERL_NIF_INIT(...)

, während dies gelungen

extern "C"
{
   ERL_NIF_INIT(...)
}

ich stark vermuten, dass dieses Problem aufgrund der gleichen Ausgabe ist aber mit dem DRIVER_INIT Makro für einen erlang-Port-Treiber.

Answer 4

Driver_Init ist die Hauptschleife, die erklärt, dass "TWinDynDriverCallbacks WinDynDriverCallbacks;" aber es ist richtig in der mehrzeilige erklärt definiert für driver_init. Sie sollten nicht brauchen, um es in extern "c" wrap.

, da dieser Thread über eine Million Mal kam, während meine Barebone versuchen, Setup erlang-Port-Treiber werde ich das hier sagen. Ich arbeite von Joe Armstrong Programmierung erlang Buch, Kapitel 12 Schnittstellen-Techniken. Mit erl5.9 und VS2010.

Der Code in dem Buch hatte eine Unterlassung und einen Fehler in example1_lib.c. Obwohl der Fehler höchstwahrscheinlich aufgrund des Alters des Buchs im Vergleich zu erlang Versionsänderungen.

benötigt, um Satz (#define WIN32 ) an der Spitze der example1_lib.c sonst erlang notleidenden an alle Linux-Optionen.

Zweite musste Änderung (int BuffLen) bis (ErlDrvSizeT BuffLen) in example_drv_output.

Danach ist es sauber gebaut.