[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
http://www.gnu.org/software/libtool/
http://savannah.gnu.org/cgi-bin/viewcvs/libtool/libtool/libltdl/
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
mk-static-filter.pl 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. ;-)
cu
Xris
cu
Xris
- [aspell-devel] MSYS patch, (continued)
- [aspell-devel] MSYS patch, Kevin Tew, 2005/02/02
- Re: [aspell-devel] MSYS patch, Kevin Tew, 2005/02/04
- Re: [aspell-devel] MSYS patch, Gary Setter, 2005/02/06
- Re: [aspell-devel] MSYS patch, Kevin Atkinson, 2005/02/07
- Re: [aspell-devel] MSYS patch, Gary Setter, 2005/02/07
- Re: [aspell-devel] MSYS patch, Kevin Atkinson, 2005/02/07
- Re: [aspell-devel] MSYS patch, Gary Setter, 2005/02/07
- Re: [aspell-devel] MSYS patch, Kevin Tew, 2005/02/07
- Re: [aspell-devel] MSYS patch, Gary Setter, 2005/02/07
- Re: [aspell-devel] MSYS patch, Christoph Hintermüller, 2005/02/08
- Message not available
- Re: [aspell-devel] MSYS patch,
Christoph Hintermüller <=
- Re: [aspell-devel] MSYS patch, Kevin Atkinson, 2005/02/07