x86/x64 DLL nutzen

afk143

Hallo,

ich habe eine x86-DLL, die ich für ein 64Bit-OS nutzen möchte. Dazu habe ich in VS2008 2 Konfigurationen erstellt:

für x86 und
für x84.
Um später beide DLL's nicht zu verwechseln, erhält der Ausgabenamen der 64Bit DLL den Präfix x64:
Ergebnis: library.dll und library.lib bzw. libraryx64.dll und libraryx64.dll.
Das aufrufende Programm findet aber die x64- DLL nicht, obwohl diese mit
#pragma comment(lib,"c:\...\libraryx64.dll" eingebunden ist. Compiliern/Linken klappt, nur bei Programmstart kommt dann der Fehler.
Wird die 64Bit Dll aber ohne den zusätzlichen Präfix gebildet, dann funktioniert alles. Diese Variante wollte ich aber vermeiden.
Kann mir jemand helfen?

Jochen Kalmbach

Deine Zeile: "#pragma comment(lib,"c:\...\libraryx64.dll"" ist falsch. Diese müsste:

#pragma comment(lib,"c:\...\libraryx64.lib")

lauten.
Auch sind absolute Pfadangaben immer schlecht... verwende bitte relative.

Und WAS für eine Fehlermeldung kommt genau, wenn Du die EXE startest? Ist die EXE auch x64? Liegt die dll im gleichen Verzeichnis wie die EXE? Das wird _nicht_ durch den Build gemacht!

Martin Richter

Am Postfix 64 liegt es sicher nicht. Vermutlich existiert die DLL ohne Postfix einfach noch und die falsche Datei wird verwendet.

Du kannst das auch mal mit DEPENDS.EXE kontrollieren welche DLL verwendet werden soll und welche geladen wird.

Vielen Dank für die ersten Antworten.
@Jochen:

#pragma comment.... dll war ein Tippfehler beim Forum, in Programm steht lib
x64 DLL ist im gleichen Verzeichnis wie aufrufendes Programm
@Martin:
Fehlermessage: DasProgramm kann nicht gestartet werden, da library.dll auf dem Computer fehlt.... (ich habe dort ja meine libraryx64.dll auf der ich im pragma auch verweise)

afk143

Ergänzung:

Dependency Walker zeigt keine DLL's an, da meine ja zur Laufzeit eingebunden werden.
meine aufrufendes Programm ist auch ein x64
Antwort vom "Verfasser" war ich - verursacht durch fehlerhaftes login

Softwaremaker

Lade die Exe in depends und starte das Profiling (Menü oben) oder F7-Taste, dann startet die exe und lädt die dlls.

afk143

Mit neuer Version von DEPENDS.EXE kann ich mein Testprogramm starten und sehe aber den gleichen Fehler: library.dll nicht gefunden.
Neu ist zusätzlich: IESHIMS.DLL nicht gefunden. (ist nicht von mir)

Jochen Kalmbach

Wenn beim starten der Applikation eine Fehlermeldung kommt, dann wird die DLL *nicht* dynamisch geladen sondern direkt beim Start!!!

Auch deutet die Fehlermeldung darauf hin, dass Du die *nicht x86" DLL in Deinem x64 Projekt referenziert hast! Somit kann er die natürlich nicht finden.

Ich vermute, dass Du nicht alle relevanten Stellen in Deinen x64-Projekteinstellungen angepasst hast; sondern irgendwo auch einen Namen ohne "x64" hast.... in der LIB muss auf jeden Fall der verweis auf die x64-DLL drin stehen; das kann Du ja mal mit "dumpbin /all NameDer.lib" anzeigen lassen....

hustbaer

@afk143
Kann es sein dass du die "libraryx64.dll" als "library.dll" baust, und dann umbenennst?
Das würde dein Problem nämlich auch erklären.
Die generierte .lib hätte dann nämlich noch "library.dll" drinstehen -- dass das .lib File umbenannt wurde ist dabei vollkommen egal.

afk143 schrieb:

Neu ist zusätzlich: IESHIMS.DLL nicht gefunden. (ist nicht von mir)

Kannst du ignorieren.
Das wird über 1000 Ecken als Delay-Load reingezogen -> macht keine Probleme wenn die DLL nicht da ist.

afk143

noch einmal zusammengefasst:

meine Bibliothek ist als x64 compiliert (eingestellt unter Konfiguration) und nur in den Projekteinstellungen (Eigenschaftenseiten) unter Reiter Linker-Allgemein-Ausgabedatei der Präfix "x64" eingefügt.
Mein aufrufendes Programm referenziert in der pragma- Anweisung die libraryx64.lib
Vorschlag der Nutzung von dumpbin
meine library.lib: machine 14c (i386)
meine libraryx64.lib: machine 8664 (unknown)
Liegt hier das Problem?
Aber ein Umbenennen der libraryx64.dll in library.dll löst das Problem! Es muss also eine x64 DLL sein, denn das Kopieren der library.DLL in das Programmverzeichnis ergibt einen Fehler "Anwendung konnte nicht gestartet werden..." Ist ja eine x86DLL die vom x64 Programm aufgerufen werden soll.

Jochen Kalmbach schrieb:

Auch sind absolute Pfadangaben immer schlecht... verwende bitte relative.

Was bedeutet absolute bzw. relative Pfade?

Jochen Kalmbach

Du hast in den Projekteinstellungen der LIB etwas falsch... sonst würde er nicht auf die DLL ohne x64 verweisen und diese laden zu versuchen...

afk143

Irgendwie drehen wir uns im Kreis.
Was kann ich in der LIB- Projekteinstellung falsch gemacht haben? Wo sind noch Einstellungen durchzuführen. Die LIB besteht aus einer einzigen Datei. Diese heißt z.B. library.cpp. Daraus wird eine library.dll/library.lib gebildet. Nur unter der x64- Projekteinstellung wird der Name der Ausgabedatei modifiziert, so dass eine libraryx64.dll/libaryx64.lib ensteht. Sind in irgendwelchen anderen Eigenschaftsseiten weitere Modifikationen notwendig?
Projekt wird mit VS2008 erstellt.
Im aufrufenden Programm verweise ich eindeutig auf libaryx64.lib.

Jochen Kalmbach

in der libraryx64.lib steht aber die "library.dll" drin, sonst würde er diese nicht beim starte verlangen wollen...

afk143

@Jochen
Wie kann ich VS2008 dazu bringen, dass aus meiner Datei library.cpp nun eine DLL erstellt wird, die den Namen libraryx64.dll trägt. Ich habe unter der x64 Konfiguration nur in den Eigenschaftsseiten unter KONFIGURATIONSEIGENSCHAFTEN-LINKER->AUSGABEDATEI folgendes stehen (OutDir)\\(ProjektName)x64.dll. Leider finde ich keine andere Eigenschaft, die Auswirkungen auf den Namen der Bibliothek hat.

Martin Richter

Das ist doch OK. Diese Methode funktioniert aber nicht mehr unter VS-2010.

Warum nimmst Du nihct die Seite General -> Targetname.

Dann musst Du nirgends rumwühlen, da ändert man mit einem Schlag alles.
Bei mir steht bei der Linkerausgabe immer nur $(OutDir)$ (TargetName)$(TargetExt)

afk143

Leider finde ich in meiner deutschen Version von VS-2008 unter allgemeine Eigenschaften keine Möglchkeit, den Zielnamen zu ändern.

Martin Richter

Gleich der oberste Reiter/Eintrag in den Einstellungen/Baum.
Sowas wie Allgemein.

Anmerkung:
Genau das ist der Punkt. Alle vernünftigen Anleitungen und Dokussind in Englisch, warum also mit der schlecht übersetzten deutschen Version arbeiten.

afk143

In den Eigenschaftsseiten ist der erste Eintrag "Allgemeine Eigenschaften".Dort sind nur Verweise eintragbar, aber es kann kein Name der DLL festgelegt werden. Mein Ziel ist es, dass ic über Menü ERSTELLEN/Funktion BATCH ERSTELLEN meine beiden Konfigurationen x86/x64 auf einmal übersetzen kann. Deshalb muss der Name der DLL konfigurationsabhängig geändert werden können. Wie schon eingangs erwähnt funktioniert alles, wenn ich beide DLL-Namen gleich halte. Aber dann weiss ich nicht, ob nun gerade die 32Bit oder die 64Bit DLL in einem Verzeichnis ist.

nn

Wir benutzen meist auch die deutsche Version, haben dabei keine Probleme verschiedene DLL-Versionen mit verschiedenen Namen in unterschiedliche Verzeichnisse zu schreiben (Debug/Release, x86/x64). Das geht unter Eigenschaften -> Konfigurationseigenschaften -> Linker -> Ausgabedatei. Da tragen wir den relativen Pfad zur Projektwurzel ein. Für die lib Datei unter Linker -> Erweitert -> Importbibliothek.

Martin Richter

nn schrieb:

Wir benutzen meist auch die deutsche Version, haben dabei keine Probleme verschiedene DLL-Versionen mit verschiedenen Namen in unterschiedliche Verzeichnisse zu schreiben (Debug/Release, x86/x64). Das geht unter Eigenschaften -> Konfigurationseigenschaften -> Linker -> Ausgabedatei. Da tragen wir den relativen Pfad zur Projektwurzel ein. Für die lib Datei unter Linker -> Erweitert -> Importbibliothek.

Das verändern der Linker Ausgabe Einstellungen führt in VS-2010 und später zu Problemen. Man sollte den Projketnamen auf der "General" Seite verändern!