Wo müssen DLLs hin ?

[Mathias]

Eine Frage an Windows-Freaks.

Ich habe in mein Projekt Verzeichniss eine SDL3.DLL kopiert.

Aber wen ich mein Projekt kompiliere, motzt er "Error: import library not for SDL3".
Muss die DLL irgendwo in windows/system rein ?


Oder ist mit dieser Zeile in meiner Source etwas nicht in Ordnung. Unter Linux geht alles einwandfrei.

Code: Alles auswählen

{$LinkLib 'SDL3'}

[Levario]

Ja sie sollte zusätzlich in den C:/Windows/System32 Ordner
Du musst zusätzlich die Datei in der selben Bit Version wie dein Lazarus vorliegen haben.

[Mathias]

Ja sie sollte zusätzlich in den C:/Windows/System32 Ordner

Dies auch bei einem 64Bit Windows ?

[MmVisual]

Es reicht vollkommen aus wenn die DLL im gleichen Ordner wie wie EXE liegt, da sucht die EXE als erstes nach der DLL.

Ich vermute mal dass die DLL "SDL3.dll" heißt und nicht nur "SDL3".

Ich würde niemals einfach so in irgend ein System Verzeichnis irgend etwas rein kopieren, damit schafft man sich nur Probleme beim Verteilen der EXE.

Abgesehen davon würde ich diese bekannte DLL dynamisch laden und nicht fest rein linken. Damit kann die EXE eine Sinnvolle Fehlermeldung erzeugen wenn die DLL nicht gefunden wurde oder in einer flaschen Version existiert.

[TSchnuckenbock]

Wir verwenden auch eine externe dll in unserem Softwarepaket.
Wenn wir vergessen, die dll in dasselbe Verzeichnis wie die exe zu legen, kommt beim Start gleich Gemecker von wegen die BliBlaBlubb.dll fehlt.

Ich hab' mal eben nachgesehen, wie ich das damals gemacht hatte. So wie ich das sehe, hatte ich einfach nur einen Header mit den Funktionen aus der dll geschrieben. Das sieht dann z.B. mit einer Funktion "api_GetApiVersion", die in der BliBlaBlubb.dll steckt, so aus:

Code: Alles auswählen

interface

const

LIB_NAME = 'BliBlaBlubb.dll'; 

procedure api_GetApiVersion(var AMajVer: int32_t; var AMinVer: int32_t); cdecl; external LIB_NAME;
  

Ich glaube, mehr mache ich da nicht. Ich nutze die Funktion dann in meinem Programm, indem ich in der Unit diese Header-Datei in die Uses-Klausel packe und dann "api_GetApiVersion(..." aufrufe.

[fliegermichl]

Das Problem mit statisch eingebundenen DLL's ist, dass, wenn sie nicht gefunden werden kann, das gesamte Programm nicht startet.
Deswegen lade ich die DLL's dynamisch.

Code: Alles auswählen

uses dynlibs;
const

LIB_NAME = 'BliBlaBlubb.dll'; 
type
 Tapi_GetApiVersion = procedure api_GetApiVersion(var AMajVer: int32_t; var AMinVer: int32_t); cdecl; 
 
var
 api_GetApiVersion : Tapi_ApiGetVersion;
 dllHandle : THandle;
begini
 if (FileExists(LIB_NAME)) then
 begin
  dllHandle := LoadLibrary(LIB_NAME);
  api_ApiGetVersion := GetProcAdress(dllHandle, 'api_ApiGetVersion');
 end else
  ShowMessage(LIB_NAME + ' nicht gefunden');
 end;
 

Man kann jetzt darauf reagieren, wenn die DLL oder die aufzurufende Procedure nicht gefunden wurde.

[Mathias]

Es reicht vollkommen aus wenn die DLL im gleichen Ordner wie wie EXE liegt, da sucht die EXE als erstes nach der DLL.

Jetzt funktioniert es, ich habe festgestellt, das das Lazarus in meiner Win-VB nur 32bit ist.
Als ich die EXE aus meinem Cross-Compiler von Linux aus tat, klappte es, dort kann ich Win64 bauen.

Ich vermute mal dass die DLL "SDL3.dll" heißt und nicht nur "SDL3".
Es geht ohne dll, folgende Zeile reicht

Code: Alles auswählen

{$LinkLib 'SDL3'}

Nun habe ich das nächste Problem in einem Mini-Programm klappt es bestens.
Aber will ich es in einer Package verwenden, spuckt Lazarus folgendes aus, obwohl ich die DLL auch in meine Project-Verzeichnis kopierte.

Code: Alles auswählen

Project1.pas(27,1) Error: Import library not found for SDL3

Woran könnte die liegen ?

Jetzt habe ich gerade in Minimalst Programm gemacht.

Code: Alles auswählen

program project1;
{$LinkLib 'SDL3'}
begin
end.    

Auch da motzt er, obwohl die DLL dort auch reinkopiert wurde.
Gibt es für wine auch eine Art "ldconfig" ?

[Mathias]

Ich bin noch ein kleiner Schritt weiter gekommen.
Wen ich folgendes Programm mache, wird es kompiliert.

Code: Alles auswählen

program Project1;

{$LinkLib 'SDL3'}

procedure SDL_GetVersion(ver: Pointer); cdecl; external;

begin
end.

Entferne ich aber die Zeile mit "procedure...external", kommt wir dieser Fehler.

Code: Alles auswählen

Project1.pas(8,1) Error: Import library not found for SDL3

[PascalDragon]

Aber wen ich mein Projekt kompiliere, motzt er "Error: import library not for SDL3".
Muss die DLL irgendwo in windows/system rein ?


Oder ist mit dieser Zeile in meiner Source etwas nicht in Ordnung. Unter Linux geht alles einwandfrei.

Code: Alles auswählen

{$LinkLib 'SDL3'}

{$Linklib ...} ist für statische Bibliotheken unter Windows (die unter Linux auch für dynamische Bibliotheken geht, auf Grund von Unterschieden wie Bibliotheken in ELF und PE/COFF behandelt werden). Die korrekte Verwendung für dynamische Bibliotheken (DLL unter Windows, so unter Linux) ist die „external Library name Funktion”-Syntax (und für macOS schmeißt man nur für das noch zusätzlich ein {$Linklib ...} rein).

[Mathias]

Ich bin einen einen Schritt weiter gekommen.
Die DLL ist in meinem Project-Verzeichniss. Ich habe eine Package für SDL3 gemacht, welche unter Linux problemlos läuft.
Wie schon gesagt, tut nur die Crosscompiler blöd.

Was ich jetzt in meinem Project gemacht habe, ich habe die package SDL3 einfernt, und dafür habe ich den Ordner wo sich die package befindet, in den Unit-Pfad des Projektes aufgenommen. Jetzt kompiliert und startet anschliessend das Programm mit wine.

Nun habe ich den Unit-Pfad wieder entfernt und die package eingebunden. Jetzt läuft es auch, bis ich den "lib" Ordner in der Package und in meinem Projekt lösche. Dann geht das Spiel wieder von vorn los.
Kompiliere ich die Package alleine, das funktionier auch.

So wie es aussieht, wen man eine DLL in einer normalen Unit einbindet, geht es,. Aber sobald es in einer Package ist, gibt es Probleme.

[Acia6850]

Hallo,

im Anhang ein kleines Projekt mit Win 64 C++Dll + Win64 Lazarus Dll + Win64 Exe zum Aufrufen der Funtionen.

Der C++ Code kann mit dem kostenlosen Embarcadero Dev-C++ 6.3 kompiliert werden
Die kompilierte CLib ist dabei.

In Windows sind die Dll's meist im Exe Verzeichnis der Windows Exe.
Muss aber nicht sein, man kann sie auch in ein eigenes Verzeichnis speichern.
Dann muss der Pfad und der Name der Dll beim Laden angegeben werden.

Ich lade sie immer dynamisch dann kann man den Fehler abfangen wenn sie nicht geladen werden können.

In Windows werden die Dll's in der Regel mit stdcall in der Function aufgerufen.

function xLazHelloFncA(szRsp : PAnsiChar) : PAnsiChar; stdcall; (nicht cdecl)

[Mathias]

Ich bin immer noch am üben mir den Windoof DLLs. Daher habe ich mal eine Standard-DLL genommen, die bei jedem Windoof dabei sein müsste.

Unter Linux geht sowas ohne Probleme.

Code: Alles auswählen

$LinkLib 'GL'}
  procedure glClear(mask: longword); cdecl; external;
begin
  glClear(0);
end.

Versuche ich dasselbe mit Windoof, findet er die DLL nicht, ich habe nur folgende Zeile ersetzt.

Code: Alles auswählen

{$LinkLib 'opengl32.dll'

Lasse ich das $LinkLib weg und geben den Libname direkt an, dann wird es gefunden.

Code: Alles auswählen

  procedure glClear(mask: longword); cdecl; external 'opengl32.dll';

Bei Linux gehen beide Varianten.

Wen ich die jetzt beschrieben Varianten angucken, sind dies doch alles statischen Einbindungen, oder habe ich da etwas übersehen ?

So wie es mir bekannt ist, geht das dynamische Laden nur über LoadLibrary().

Oder habe ich das ganze immer noch nicht verstanden ?

[Acia6850]

Hallo,

wann cdecl oder stdcall !

[Windows DLL]
Libs in Windows meist stdcall auch Windows Api.
Libs in Windows wenn c oder c++ können auch unter windows mit cdecl aufgerufen werden wenn sie vom Entwickler so definiert sind.
Ich habe immer DLLs, welche in Delphi, Lazarus und C/ C++ in Windows programmiert wurden mit stdcall deklariert.
Sie wurden auch ohne Probleme von den Anwendern in Windows so eingebunden.

[Linux]
Bei Linux habe ich eine .so gemacht und mit cdecl definiert.

[Linken in Windows]

Die Dll kann statisch gelinkt werden mit z.B procedure xyz(n : Longint); stdcall; external 'xyzLib.dll';

Vorteil einfacher Code.
Nachteil bei Fehler in Dll oder Dll nicht vorhanden. Absturz der Hauptprogrammes.

Die Dll dynamisch linken mit LoadLibrary ..

Vorteil man kann die Fehler zur Laufzeit abfangen. Dll zur Laufzeit laden und entladen.
Nachteil Code aufwändiger.

Es gibt noch eine dritte Möglichkeit mi c/c++ Libs

Wenn man den code der c/c++ Lib als Obj Datei oder als statische c/c++ Lib hat und Lazarus die dazugehörigen Runtime Libs einbinden kann , gibt es die Möglichkeit in Windows
die Funktionen der LIB statisch in die Lazarus Exe zu linken dann aber mit cdecl weil es c/c++ Funktionen sind.

z.b. {$Linklib ..\Lib\x86_64-win64\libmsvcrt.a}

Ob das in Linux funktioniert habe ich noch nicht getestet.

So kann man z.b. die SQlite.Dll als Lib in Lazarus einbinden in die Exe.

[Mathias]

Danke für die Infos.
So wie es scheint, gibt es zwischen den OS viele kleine Unterschiede, welche einem das ganze unangenehmer machen,
Was ich gerade feststellen musste, OpenGL > 1.2 wird es echt kompliziert, die scheine da unter Windows was ganz eigenes zu haben. Unter Linux kann man statisch reinlinken, wie jede andere Lib auch.

[m.fuchs]

Moderationshinweis: Die Windows vs. Linux-Diskussion habe ich mal abgetrennt und verschoben.