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. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel