Regarding a similar subject, I found an article by Hallvards Vassbotn showing a method to delay load dlls in Delphi, its usage is pretty similar to static linking, but the library is loaded on demand (without explicitly calling LoadLibrary).
This is a short version: http://hallvards.blogspot.com/2008/03/tdm8-delayloading-of-dlls.html The long PDF version: http://vassbotn.googlepages.com/DelayLoadingOfDLLs.pdf Leonardo M. Ramé http://leonardorame.blogspot.com --- On Wed, 11/11/09, Marco van de Voort <mar...@stack.nl> wrote: > From: Marco van de Voort <mar...@stack.nl> > Subject: Re: [fpc-devel] Dynamically Loading Libraries > To: "FPC developers' list" <fpc-devel@lists.freepascal.org> > Date: Wednesday, November 11, 2009, 8:54 AM > In our previous episode, Jeppe > Johansen said: > > >> procedure proc; > external name 'proc'; > > >> denotes a static linked function. > > >> > > > > > > This syntax is not possible. The external 'xxx' > name 'proc' is there for a reason, > > > for systems with multiple linker namespaces. > Moreover there is already an > > > enormous codebase that uses this. > > > > > I don't know if I'm making a fool of myself, but what > systems? Skimming > > the sources, I couldn't find any mention of it in the > ELF writers. An > > external symbol will simply be linked to the first > occurrence of a > > matching symbol in the first shared or static > object(unless there's some > > name mangling going on that I didn't spot). The COFF > writer already does > > it the way I suggested. > > Windows, Darwin, and afaik Solaris. The ELF writers are > probably not updated > for Solaris yet. > > > >> 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 > > > > > > I don't. I think this dynamically loading of > headers has already gone to > > > far. It is a good workaround for a few headers > that are versionwise a > > > disaster, like MySQL, but universally, it doesn't > solve problems. > > > > > In principle, doing it this way would make cross > compiling to an ELF > > platform with dynamic linking easier, once the > internal ELF linker is > > made. > > While partially true, this is a brute force approach. > Having a few simple > map files (that can be generated on target from the libs) > over which files > contain which symbols might help too. > > > _______________________________________________ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
