[fpc-pascal] -Twin32 linker woes

[Tomas Hajny]

On Thu, March 11, 2010 12:28, Adriaan van Os wrote:
> Marco van de Voort wrote:
>> In our previous episode, Adriaan van Os said:
>>> I am cross compiling with fpc svn trunk and -Twin32 on i386 Mac OS X to
>>> Win32. This works fine,
>>> except that {$linklib xxx.dll} says
>>
>> dlls are usually not $linklib'ed in FPC. What happens if you simply omit
>> the
>> linklib?
>
> Well, then the linker complains about unresolved symbols.
>
> Does that mean that LoadLibrary and GetProcAddress must be called for all
> external dll calls ?

No, certainly not. Normally, something like the following would be used:

function FreeLibrary (hLibModule:HINST):WINBOOL; external 'kernel32' name
'FreeLibrary';

I.e. function FreeLibrary is imported from kernel32.dll. Note that in this
case the declaration also includes information on the external name; I
believe that a mangled (or at least uppercase) name would be expected
otherwise (at least in the past the expected mangled name depended on the
specified calling convention in FPC - as opposed to some other compilers
which allow specifying mangling independently from calling conventions).
Note that this doesn't work for the OS/2 target (my primary domain)
because functions are usually imported from dynamic libraries by their
ordinal numbers there (which is also why I don't know the details for
WinXX for sure except that the above works).

Another alternative (common with some compilers for OS/2, but usually not
used with FPC) might be using an explicitly generated import library. Such
an import library is just a static library containing "translation" of
symbols defined as externals in the pascal source code to invocation of
the respective dynamic library routines. If you do this, you need to make
sure that the names defined in the import library match those expected by
the compiler for the external symbol (i.e. that there isn't some/different
mangling in place). I believe that you tried doing this in one of your
attempts (but I may be wrong there).

Tomas