[fpc-pascal] FPC linker oddity

[Tomas Hajny]

On Sun, June 21, 2015 22:58, Jonas Maebe wrote:
> On 21/06/15 22:20, patspiper wrote:
>> On 21/06/15 23:08, Jonas Maebe wrote:
>>> On 21/06/15 21:43, patspiper wrote:
>>>> Changing the GetTickCount declaration to any of the following works:
>>>>    Function GetTickCount: DWORD; external name
>>>> '_$dll$kernel32$GetTickCount';
>>>>    Function GetTickCount: DWORD; external 'kernel32';
>>>>
>>>> Why is the behaviour different between Linux and Windows?
>>> ELF (used by Linux) and PECOFF (used by Windows) use completely
>>> different ways of shared linking.
>> So what should be done to remedy the Windows case when $LINKLIB is used,
>> that is unless $LINKLIB is not to be used with Windows?
>
> {$linklib xxx} can be useful on Windows if you have a DLL that has an
> initialisation routine that you want to be run, but you're not calling
> any code from it.
>
>> Note that in the 2 'solutions' I gave, $LINKLIB is not needed and can be
>> removed altogether.
>
> That's correct. And the second way is the normal way to import routines
> from a DLL under Windows (which also works under *nix; only Darwin is
> different for legacy reasons: there you need the {$linklib xxx} to
> ensure that the library is linked).
>
> Using both {$linklib xxx} and "external 'xxx'" is best, since it will
> always work on all platforms.

I'm not sure if it is really the best. At least FPC 2.6.4 expects that the
LINKLIB ... refers to an (existing) import library and issues 'Error:
Import library not found for kernel32', whereas the import library is
generated on the fly based on the import declarations of the individual
external symbols if LINKLIB is not used.

Tomas