[fpc-devel] Dynamically Loading Libraries

[Jeppe Johansen]

Jonas Maebe wrote:
>>   procedure proc; external 'libname' name 'proc';
>> denotes a function that's dynamically loaded implicitly, while
>>   procedure proc; external name 'proc';
>> denotes a static linked function.
>>
>> In my opinion that seems like the only logical solution. Explicit 
>> dynamic loading will ofcourse still be possible, but you wouldn't 
>> need tools or lots of ifdefs
>>
>> I'm not aware of how well it would work on Mac platforms, but I'm 
>> mostly certain most GNU/Linux and BSD's, and Windows has support for 
>> implicit dynamic linking in the executable formats
> What about saying that
>
> What do you mean by "implicit dynamic linking"?
Using a runtime linker. On windows implicit dynamic loaded functions are 
written in the .idata section. And using dynamic runtime linking on 
GNU/Linux, with dl
>> This is ofcourse a solution that would require modification of the 
>> compiler, but I think in the long run that it'll make alot of things 
>> more comprehensible
>
> It would also require modifications to several existing header 
> translations, and depending on what "implicit dynamic linking" means, 
> it would also make it impossible to use the same unit for static and 
> for dynamic linking, while this is currently possible. It would also 
> break backwards compatibility. And like Marco I'm not sure what the 
> big problem is that is solved with this. 
If this method was implemented we could make both methods possible like this

{$ifdef LINKSTATIC}
const
  libname := '';
 {$ifdef LINUX}
  {$l library}
 {$endif}
 {$ifdef WIN32}
  {$l library}
 {$endif}
{$else}
const
 {$ifdef LINUX}
  libname := 'library.so';
 {$endif}
 {$ifdef WIN32}
  libname := 'library.dll';
 {$endif}
{$endif}

procedure ImportedFunction; external libname name 'ImportedFunction';
procedure ImportedFunction2; external libname name 'ImportedFunction2';

I hope I get the point across :)