Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Mo Jun 17, 2024 11:02

Foren-Übersicht » Programmierung » Allgemein
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 8 Beiträge ] 
Autor Nachricht
BeitragVerfasst: Fr Nov 04, 2011 02:30 
Offline
DGL Member
Benutzeravatar

Registriert: Di Apr 29, 2008 18:56
Beiträge: 1213
Programmiersprache: Delphi/FPC
Hey,

ich entwickle zur Zeit mit Lazarus 64 und Windows7. Für mein Projekt benötige ich die glBitmap. Dort hab ich eingestellt, das er zum laden für PNGs und JPEGs die libPNG bzw. libPNG benutzen soll. Beim kompilieren hat er mir dann gesagt das er die c.dll nicht finden kann. Also hab ich mich durch den Code gewühlt und folgende Stelle in der libPNG bzw. libJPEG gefunden:
Code:
  1. {$IFDEF FPC}
  2.   {$MODE Delphi}
  3.  
  4.   {$IFDEF CPUI386}
  5.     {$DEFINE CPU386}
  6.     {$ASMMODE INTEL}
  7.   {$ENDIF}
  8.  
  9.   {$IFNDEF WIN32} //hier
  10.     {$LINKLIB c}
  11.   {$ENDIF}
  12. {$ENDIF}

Das kann ja so nicht gehen. Ich bin zwar unter Windows, aber eben nicht auf 32bit. Also hab ich die Zeile folgendermaßen abgeändert:
Code:
  1. {$IFDEF FPC}
  2.   {$MODE Delphi}
  3.  
  4.   {$IFDEF CPUI386}
  5.     {$DEFINE CPU386}
  6.     {$ASMMODE INTEL}
  7.   {$ENDIF}
  8.  
  9.   {$IF NOT(DEFINED(WIN32) OR DEFINED(WIN64))} //hier
  10.     {$LINKLIB c}
  11.   {$ENDIF}
  12. {$ENDIF}

Damit kompiliert er das Programm jetzt ohne Probleme. Also hab ich das erstmal zu den Akten gelegt und an einigen anderen Stellen des Projektes weiter gearbeitet. Und auf einmal bringt er mir nach dem Kompilieren, beim Initialisieren des Programms die Fehlermeldung, das er die c.dll nicht finden kann. Also hab ich mich wieder durch den Code gewühlt und herausgefunden, das die Meldung kommt sobald das Programm ein TglBitmap2D.Create beinhaltet. Die Zeile muss dazu nicht abgearbeitet werden, sie muss nur im Code vorhanden sein, dann kommt der Fehler. Zur Sicherheit hab ich das {$LINKLIB c} mal komplett raus genommen (brauch ich ja unter Windows eh nicht) aber das hat leider nix geändert.
Hat jemand von euch ne Idee was ich da machen kann, bzw wie ich den Fehler weg bekomm? Ein Link zur c.dll würde mir vlt auch schon was helfen (sofern die dll unter Windows überhaupt geht), die hab ich bis jetzt noch nich gefunden.

Crosspost Delphi-Forum

MfG & Thx Bergmann89.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Mo Nov 14, 2011 22:35 
Offline
DGL Member
Benutzeravatar

Registriert: Di Apr 29, 2008 18:56
Beiträge: 1213
Programmiersprache: Delphi/FPC
Keiner ne Idee? :( Die Units sind doch von Lossy eX, oder? Hast du vlt ne Idee dazu?

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Nov 17, 2011 11:52 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Ja. Die sind von mir. Steht ja auch in den Units ganz oben drin. :twisted:

Zu deinem Problem. Keine Ahnung. Die Defines basieren aus dem der dglopengl. Warum da wie wo was so sein muss weiß ich nicht, da linux und/oder fpc nie mein Hauptinteresse waren. Die hatte irgendjemand der unter Linux arbeitet beigesteuert. Versuch mal das aktuelle Define aus der dglopengl (die unter linux ja wohl funktioniert). Vielleicht hilft das. Wenn nicht mach es mal ganz weg. Geht das auch nicht musst du dir jemanden suchen der unter Linux entwickelt.

Code:
  1. {$IFDEF FPC}
  2.   {$MODE Delphi}
  3.  
  4.   {$IFNDEF WINDOWS}
  5.     {$LINKLIB c}
  6.   {$ENDIF}
  7. {$ENDIF}


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Do Nov 17, 2011 13:34 
Offline
DGL Member
Benutzeravatar

Registriert: Di Apr 29, 2008 18:56
Beiträge: 1213
Programmiersprache: Delphi/FPC
Hey,

komplett löschen hatte ich auch schon probiert, geht aber nicht. Der Fehler war auch gar nicht dort oben, sondern bei den ganzen anderen IFDEFs im Code. Da wurde ja auf IFDEF WIN32 geprüft, also ist er immer in den ELSE Block gesprungen und wollte da die Linuxsachen ausführen. Und da hat er automatisch versucht die c-lib zu laden.
Jetzt hab ich aber schon wieder das nächste Problem :( Und zwar brauch ich ja die DLL auch als 64bit Kompilat. Also hab ich mir den Code besorgt und ihn schnell durch VS 2010 gejagt. Ich kann die DLL auch laden, aber wenn ich mit die Adresse einer Funktion holen will bekomm ich immer 0 zurück und GetLastError sagt Fehler 126 "The specified module could not be found." Ich hab die DLL mit nem Viewer geöffnet und nachgesehen, die Funktionen sind eigentlich drin...

€: OK, habs gelöst. Die Funktionen sind beim FreePascalCompiler falsch definiert. Da wurde anstatt eines PInteger ein Cardinal für das Handle der DLL benutzt. Danke für die Hilfe :)

MfG Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Nov 18, 2011 11:08 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Nichts für ungut aber wie soll dir denn jemand bei solchen Ausführen folgen können?


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Fr Nov 18, 2011 12:27 
Offline
DGL Member
Benutzeravatar

Registriert: Di Apr 29, 2008 18:56
Beiträge: 1213
Programmiersprache: Delphi/FPC
Sry, ich hatte versucht mich kurz zu fassen, war vlt etwas zu kurz.

Also zum ersten Fehler. Mal als Bsp an diesem Codeauschnitt:
Code:
  1. {$ifdef WIN32}
  2.   libPNG_Handle := LoadLibrary(pAnsiChar(libPNG_Name));
  3. {$else}
  4.   libPNG_Handle := dlopen(pAnsiChar(libPNG_Name), RTLD_LAZY);
  5. {$endif}
Da ich unter Win64 arbeite wird hier der Code im ELSE-Block ausgeführt. Und beim Aufruf der dlopen-Funktion will er automatisch die c.dll einbinden (die es ja unter Windows nicht gibt). Also hab ich einfach aus all den {$IFDEF WIN32} im Code ein {$IFDEF WINDOWS} gemacht und schon war das erste Problem beseitigt.

Das zweite Problem bestand darin, das ich in einem 64bit Programm keine 32bit DLL laden kann. Also hab ich mir den Code von zlib und libPNG besorgt und mit Visual Studio 2010 eine DLL auf 64bit basis erstellt. Mit der hab ich dann versucht zu arbeiten. Beim laden mit LoadLibrary hab ich auch ein Handle bekommen, also hab ich angenommen, das die DLL richtig geladen wurde. (GetLastError hat hier ja auch keine Fehler ausgespuckt). Wenn ich jetzt aber mit GetProcAddress eine Funktion aus der DLL laden wollte wurde mir immer ein null-Pointer zurückgegeben und GetLastError hat mir Fehlercode 126 geliefert: "The specified module could not be found." Zuerst dachte ich, das die Funktion vlt beim erstellen der DLL einen anderen Namen bekommen hat, also hab ich mit nem DLL Viewer die DLL ausgelesen und mir die Namen angesehen. Die waren genauso, wie ich sie eingegeben hatte. Also musste der Fehler irgendwo anders sein. Bei der Suche nach einer Lösung hab ich dann im Netz ein Topic zu einem ähnlichen Problem gefunden. Und da hat sich herausgestellt, das LoadLibrary, FreeLibrary und GetProcAddress falsch deklariert waren. Das Handle der DLL war einem LongInt, musste aber ein PInteger sein, da LongInt unter 64bit die falsche Größe hat:
Code:
  1. //das:
  2. function LoadLibrary(lpFileName: pAnsiChar): LongWord; stdcall; external Kernel32 'kernel32.dll' 'LoadLibraryA';
  3. function FreeLibrary(hModule: LongWord): LongBool; stdcall; external Kernel32 'kernel32.dll' 'FreeLibrary';
  4. function GetProcAddress(hModule: LongWord; lpProcName: pAnsiChar): Pointer; stdcall; external Kernel32 'kernel32.dll' 'GetProcAddress';
  5.  
  6. //wurde zu dem:
  7. function LoadLibrary(lpFileName: pAnsiChar): PInteger; stdcall; external Kernel32 'kernel32.dll' 'LoadLibraryA';
  8. function FreeLibrary(hModule: PInteger): LongBool; stdcall; external Kernel32 'kernel32.dll' 'FreeLibrary';
  9. function GetProcAddress(hModule: PInteger; lpProcName: pAnsiChar): Pointer; stdcall; external Kernel32 'kernel32.dll' 'GetProcAddress';
Nach dieser kleinen Änderung hat alles so funktioniert wie es sollte :)

MfG Bergmann

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Nov 20, 2011 13:18 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Bergmann89 hat geschrieben:
Sry, ich hatte versucht mich kurz zu fassen, war vlt etwas zu kurz.
Ja. Vielleicht.

Zu dem Rest. Ja macht durchaus Sinn. Wobei ich mich da gerade Frage warum in Delphi immer nur Zahlentypen verwendet wird. Wo in den MSDNs doch auch direkt pointer verwendet werden. Wobei ein PInteger da auch eher beschränkt Sinn macht. Du derefenzierst diesen Typen ja nicht von daher ist es egal worauf der Pointer zeigt. Was vor allem, dann in init_libJPEG (und quit_libJPEG) noch wichtig ist, da dort auf 0 oder nil auf libJPEG_Handle verglichen wird. Und libJPEG_Handle müsste dann auch ein Pointer sein. Oder klappt unter FPC die Zuweisung eines Pointers auf einen Cardinal??


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Nov 20, 2011 22:47 
Offline
DGL Member
Benutzeravatar

Registriert: Di Apr 29, 2008 18:56
Beiträge: 1213
Programmiersprache: Delphi/FPC
Hey,

die Datentypen hab ich natürlich bei allen Variablen angepasst, denn in FPC nimmt er einen Pointer auf Cardinal genau so wenig an, wie im normalen Delphi. LibJPEG hab ich bis jetzt leider noch nicht als 64bit DLL kompilieren können, das steht aber noch auf dem Plan...

MfG Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 8 Beiträge ] 
Foren-Übersicht » Programmierung » Allgemein


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 45 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.079s | 17 Queries | GZIP : On ]