[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