Hello,

I am experiencing a problem with libraries on Free Pascal 2.0.2. It seams that a software cannot load 2 dlls created with Free Pascal. Loading the first library will be successfull, but loading the second library will fail. All of this is on Windows XP.

I noticed this when Apache would successfully load one module created with Free Pascal, but misteriously fail when loading a second module created on Free Pascal. Then I noticed that loading only the second module works.

Is this a known problem that I can do something to work around, or I should report this as a bug?

I was able to create a very simple example to reproduce the problem. Bellow is a empty library code:

library newlib;
{$mode objfpc}{$H+}
begin
end.

It generates newlib.dll file. Then I copy that file to create a second one newlib2.dll. It could be another library created with Free Pascal too.

Bellow is a program that will load both Libraries:

program loadmod;
{$mode objfpc}{$H+}
{$apptype console}
uses Classes, Windows;
var
  Lib, Lib2: HINST;
begin
  Lib := LoadLibrary('C:\Programas\Apache\pmodules\newlib.dll');
  Lib2 := LoadLibrary('C:\Programas\Apache\pmodules\newlib2.dll');
  WriteLn(Lib);
  WriteLn(Lib2);
  Sleep(5000);
  FreeLibrary(Lib);
  FreeLibrary(Lib2);
end.

The WriteLn statements show that the first library is loaded successfully. The second will return zero.

If the second library being loaded is not created with Free Pascal (I tested with libhttpd.dll). The load will be successfull.

thanks,

You might get a clue if you print last windows error. (sysutils.getlastoserror) after the 2nd loadlib

You might get a clue if you print last windows error. (sysutils.getlastoserror) after the 2nd loadlib

The error code is: 193 0x00C1 N/A %1 is not a valid Win32 application.

But that doesn´t make sense.

See if FPC has some directive for setting the DLL baseaddress and set it, and see if that matters.

The error code is: 193 0x00C1 N/A %1 is not a valid Win32 application. But that doesn´t make sense.

Can you try indicating another address space to be loaded in the 2nd lib?

Thursday, July 13, 2006, 4:04:05 PM, Felipe wrote:

FMdC> The error code is: 193 0x00C1 N/A %1 is not a valid Win32 application..

FMdC> But that doesn´t make sense.

May be, for some reason DLLs are created without the relocation information (or with malformed relocation info)? When you just compile two DLLs from the same source, they will have the same base address. Loading the first DLL will succeed if its base address is not occupied by some other DLL. But after that attempting to load the second DLL with the same base address would cause Windows to relocate it to another address - and without correct relocation information that would fail.

If this is the scenario, then either you specify wrong compiler options, or the compiler (or linker) really generates malformed DLLs.

I guess FPC is creating the DLL with no relocation section in it. Another issue is that meaningless error. It should be "Abnormal process termination" or the like.. :-?

Sergei Gorelkin wrote

May be, for some reason DLLs are created without the relocation information (or with malformed relocation info)?

Yes, you really guessed right =)

I found an explanation on the fpc documentation about it that says exactly that:

http://www.freepascal.org/docs-html/prog/progse53.html#x226-22800012.5

If I pass -WR option to generate the libraries, now they work.

I tryed to put that on my fpc.cfg to compile on Lazarus, but it doesn´t work. I don´t know why the generated libraries won´t work. If I go to the command line and pass the option, then it will work.

I will suggest making a checkbox for this option on Lazarus, and make it default for libraries.

Jose Manuel wrote

>> The error code is: 193 0x00C1 N/A %1 is not a >> valid Win32 application. >> >> But that doesn't make sense.

[...]

I guess FPC is creating the DLL with no relocation section in it. Another issue is that meaningless error. It should be "Abnormal process termination" or the like.. :-?

Uhuh. How come that this would make more sense? ;-)

SCNR,

Vinzent.