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