[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [aspell-devel] MSYS patch

From: Christoph Hintermüller
Subject: Re: [aspell-devel] MSYS patch
Date: Sun, 13 Feb 2005 15:29:18 +0100
User-agent: KMail/1.7.1

Hi Gary
Am Mittwoch, 9. Februar 2005 15:06 schrieben Sie:
> This is the MSDN help on the two ways to load a DLL. Note the
> Explicit linking uses LoadLibrary.
> With implicit linking, the executable using the DLL links to an
> import library (.LIB file) provided by the maker of the DLL. The
> operating system loads the DLL when the executable using it is
> loaded. The client executable calls the DLL's exported functions
> just as if the functions were contained within the executable.
> With explicit linking, the executable using the DLL must make
> function calls to explicitly load and unload the DLL, and to
> access the DLL's exported functions. The client executable must
> call the exported functions through a function pointer.
> I like dynamic linking because it gives the application a chance
> to respond if the library is not there. If you use an interface
> library and the dll is not available, the application will not
> load.
> Best regards,
> Gary
1) In unix world implicit linking is called loadtime linking while explicit 
linking is called runtime linking. Load time linking is address from a 
buildprocess view as shared linking in contrast to static linking. And the 
explicit linking is viewed as dynamic loading. From the programs/libraries 
point of view runtime linking looks the same as if everything was statically 
linked into it's binary.

2) You can even use LoadLibrary to retrieve function poitners in case of 
static linking. The best example how to do this is given by libtools libltdl 
library. Thus the simpliest way would be to linke aspell against libltdl 
instead of the systems native libdl. The libltdl implicitly takes care of 
properly retireving the function pointers. The only thing libaspell would 
need to kow if it was linked statically, dynamic at loadtime or if it is 
allowed to do runtimeloading. In case of static and loadtime linking libspell 
would have to hand a NULL filename to ltdload to ensure that only symbols 
allready loaded and linked are searched. 

For more information have a look at the sources of libltdl at

How they do that. Thus there is no need to remove LoadLibrary from libaspell 
in case of loadtime or static linking. Just tell libaspell that it schould 
assume static linking instead of runtime loading ;-). The sideeffect off 
sticking to libltdl form libtool package would be that the real static 
linking process would be come much easier too ;-) No need for the anymore ;-)

(@Kevin @Gary) If it doesn't matter that this change will take place not 
before sumemr I'd reactivate my savannha account and adopt the corresponding 
codes. ;-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]