[fpc-devel] Dynamically Loading Libraries

Joost van der Sluis joost at cnoc.nl
Thu Nov 12 11:33:59 CET 2009


On Thu, 2009-11-12 at 11:15 +0100, Jonas Maebe wrote:
> Joost van der Sluis wrote on do, 12 nov 2009:
> 
> > On Wed, 2009-11-11 at 13:21 +0100, Jonas Maebe wrote:
> >> On 10 Nov 2009, at 23:24, Jeppe Johansen wrote:
> >>
> >> > What about saying that
> >> >   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 do you mean by "implicit dynamic linking"?
> >>
> >> > 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.
> >
> > Offcourse not. For existing headers nothing changes. For new ones one
> > can add the 'lazydynamic'  keyword or something like that to the
> > definition.
> 
> The mail I was reacting to, as quoted above, said:
> 
> ***
> What about saying that    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
> ***
> 
> That would break backwards compatibility (it would no longer be  
> possible to use a unit with the first syntax for using a statically  
> linked library). You appear to be talking about some different proposal.

You're right. I missed that, sorry for that.

Joost.




More information about the fpc-devel mailing list