[SOLVED] Help debugging why LoadLibrary keeps returning zero with sample project lazarus / 62-General ---------------------------------------------------------------------- Gizmo · 2021-05-10 11:01 I've recently compiled a DLL using the 64-bit MSYS2 MinGW and it compiled successfully. I can browse it using DLL Explorer. But, I can't load it with LoadLibrary using Lazarus 2.0.12 and FPC 3.2.0 on 64-bit Windows 10. I have created a small demo project and supplied the DLL in the hope someone might look at it and see if the problem is my code, or the DLL itself. I have Googled the various reasons that LoadLibrary fails, and all the answers seem to relate to things like permissions or filenames. It keeps returning 0 with me, but I can't see WHY its returning zero, because the name string of the filename shows correctly in the debugger and the permissions are allowed to execute it and the path is valid. I've tried using Unicode string, rawbytestring, and normal string. I've tried using THandle and TLibHandle. Just can't get anything other than 0. It would be a big help if someone could try it for me and see if they can get a non-zero value? Or has the DLL being made incorrectly? DLL Explorer shows all the valid functions in it. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  procedure TForm1.Button1Click(Sender: TObject);var  //libFileName : Unicodestring;  // libFileName : RawByteString;   libFileName : string;   fLibHandle  : TLibHandle;  // fLibHandle : THandle;begin  fLibHandle := nilhandle;  //libFileName:=ExtractFilePath(Application.ExeName)+'libewf-v3.dll'; /// gets full path to DLL OK   libFileName:='libewf-v3.dll';   // if DLL in same folder as exe  if FileExists(libFileName) then    begin  fLibHandle := LoadLibrary(PChar(libFileName)); // Keeps returning zero    //fLibHandle := dynlibs.LoadLibrary(libFileName);    //fLibHandle := LoadLibraryA(PAnsiChar(libFileName));  // Windows API method    if fLibHandle<>nilhandle then      begin        Label1.Caption := 'Success';      end      else Label1.Caption := 'Failed';    end;end;  Sample project with the DLL in question here : https://we.tl/t-FeC0iquYgX ---------------------------------------------------------------------- Imants · 2021-05-10 12:22 Have you tried to call GetLoadErrorStr if result is 0 or give full path to dll file? ---------------------------------------------------------------------- Gizmo · 2021-05-10 12:31 I've just used Depenancy Walker (old tool but still valid) and it has thrown some errors with the DLL. I think I may have compiled from wrong release link. Re-trying. Will report back. Meanwhile, if anyone can see a problem with the code, recommendations welcome. ---------------------------------------------------------------------- trev · 2021-05-10 12:43 As Imants mentioned, you have no error checking! For example (from a macOS example I wrote): Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i    // load and get the dynamic library handle   LibHandle := LoadLibrary(PChar('libtest.dylib'));    // check whether loading was successful   if LibHandle <> 0 then     begin       // assign address of the subroutine call to the variable cvtString       Pointer(cvtString) := GetProcAddress(LibHandle, 'cvtString');        // check whether a valid address has been returned       if @cvtString <> nil then         WriteLn(cvtString('hello world'))       // error message on no valid address       else         WriteLn('GetLastOSError1 = ', SysErrorMessage(GetLastOSError));     end   else     // error message on load failure     WriteLn('GetLastOSError2 = ', SysErrorMessage(GetLastOSError)); ---------------------------------------------------------------------- Mr.Madguy · 2021-05-10 14:32 Two possible reasons: 1) DllMain doesn't return true for DLL_PROCESS_ATTACH. 2) This DLL has some dependencies, that aren't satisfied. ---------------------------------------------------------------------- MarkMLl · 2021-05-10 15:19 Quote from: trev on May 10, 2021, 02:43:49 pmAs Imants mentioned, you have no error checking! Be warned that I came across something similar on Linux where somebody had replaced the *content* of a shared library with a linker script: the name and everything were correct and it worked if loading were automatic, but not if the module were opened explicitly by name with the intention of checking and loading the entry points individually. MarkMLl ---------------------------------------------------------------------- jcmontherock · 2021-05-10 15:39 if I replace the name of your dll with "libmysql.dll" (64 bits) it's work. So it's a problem with your dll. ---------------------------------------------------------------------- Mr.Madguy · 2021-05-10 15:58 Your dll depends on following dlls: msvcrt.dll zlib1.dll libwinpthread-1.dll libcrypto-1_1-x64.dll Are they accessible to your project? You also need correct version of VC runtime installed. ---------------------------------------------------------------------- Gizmo · 2021-05-10 22:05 Thanks jcmontherock for trying that. I hadn't thought of that myself! Good idea. And thanks for helping me narrow down the issue. Mr M...thanks for those details. I had worked out zlib was required but I didnt realise about the others. This is enormously frustrating. I have also asked the developer. I understand the reasons for not making a DLL available (security etc) but with a library as big as this, and its dependancies, its very tricky to work out how to compile it from source. I've recently done so for SQLite, and that wasnt too tricky once I got the MinGW environment setup right. But for this I've even resorted to installing 10Gb of Visual Studio 2019 and still couldn't get a valid DLL. Probably because of these dependancies. Very frustrating. It's like being given a car with no engine in it. I think I'll leave this feature to my next version. I have more pressing things to work on right now. This was just a "nice to have" ---------------------------------------------------------------------- jcmontherock · 2021-05-11 14:38 One more point: dll type could be COFF or OMF. Embarcadero gives a program utility for converting thees types. I don't know which type Lazarus is using. ---------------------------------------------------------------------- marcov · 2021-05-11 14:57 Quote from: jcmontherock on May 11, 2021, 04:38:57 pmOne more point: dll type could be COFF or OMF. Embarcadero gives a program utility for converting thees types. I don't know which type Lazarus is using. Static libraries (and import libraries) might be COFF/OMF.  DLLs are all PE(+), or windows won't load them. ---------------------------------------------------------------------- Gizmo · 2021-05-14 08:46 I solved this in the end guys. I added some environment paths to my Advanced Windows Settings relating to bin, and lib folders of MSYS2 and MinGW64. But the real solution was that I needed an additional DLL in the same folder, in addition to Zlib1.dll, and that was C:\msys64\mingw64\bin\libwinpthread-1.dll which was needed. So I copied that to the folder, and all was well. Thanks for the help.