[fpc-devel] Dynamically Loading Libraries
Joost van der Sluis
joost at cnoc.nl
Thu Nov 12 10:54:28 CET 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.
It it now also impossible to use the same unit for dynamic ans static
loading. This is all done using ifdefs and include files generating two
units sharing the same code. This all stays the same. Or maybe we can
add a flag {$disablelazydynamic} - that way we only need one ifdef.
It has no influence on backwards compatibility.
Joost.
More information about the fpc-devel
mailing list