关于MinGW下.dll.a文件的作用

 

.dll.a文件的最初用意其实是MinGW下的DLL文件的imp-lib，即与VC下DLL文件附带了一个引入库.lib类似。在VC下编程，当要使用DLL文件时，在开发时必须要有.lib文件才能链接通过。.dll.a文件就是这样的作用。

 

但是，MinGW/Cygwin确提供了直接与.dll文件链接的作用，就是可以不需要imp-lib库文件，只要DLL文件存在，也可以链接成功。这样就导致.dll.a文件似乎不是那么有用了。在很多场合下，可以不需要.dll.a文件了。但是有几个例外情况，来自于RedHat的官方描述。

 

 

5.8. ld and WIN32 (cygwin/mingw)

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html

 

 

 

direct linking to a dll

The cygwin/mingw ports of ld support the direct linking, including data symbols, to a dll without the usage of any import libraries. This is much faster and uses much less memory than does the traditional import library method, expecially when linking large libraries or applications. When ld creates an import lib, each function or variable exported from the dll is stored in its own bfd, even though a single bfd could contain many exports. The overhead involved in storing, loading, and processing so many bfd's is quite large, and explains the tremendous time, memory, and storage needed to link against particularly large or complex libraries when using import libs.

Linking directly to a dll uses no extra command-line switches other than -L and -l, because ld already searches for a number of names to match each library. All that is needed from the developer's perspective is an understanding of this search, in order to force ld to select the dll instead of an import library.

For instance, when ld is called with the argument -lxxx it will attempt to find, in the first directory of its search path,

libxxx.dll.a xxx.dll.a libxxx.a cygxxx.dll (*) libxxx.dll xxx.dll

before moving on to the next directory in the search path.

(*) Actually, this is not cygxxx.dll but in fact is <prefix>xxx.dll, where <prefix> is set by the ld option -dll-search-prefix=<prefix>. In the case of cygwin, the standard gcc spec file includes -dll-search-prefix=cyg, so in effect we actually search for cygxxx.dll.

Other win32-based unix environments, such as mingw or pw32, may use other <prefix>es, although at present only cygwin makes use of this feature. It was originally intended to help avoid name conflicts among dll's built for the various win32/un*x environments, so that (for example) two versions of a zlib dll could coexist on the same machine.

The generic cygwin/mingw path layout uses a bin directory for applications and dll's and a lib directory for the import libraries (using cygwin nomenclature):

bin/ cygxxx.dll lib/ libxxx.dll.a (in case of dll's) libxxx.a (in case of static archive)

Linking directly to a dll without using the import library can be done two ways:

1. Use the dll directly by adding the bin path to the link line

gcc -Wl,-verbose -o a.exe -L../bin/ -lxxx

However, as the dll's often have version numbers appended to their names (cygncurses-5.dll) this will often fail, unless one specifies -L../bin -lncurses-5 to include the version. Import libs are generally not versioned, and do not have this difficulty.

2. Create a symbolic link from the dll to a file in the lib directory according to the above mentioned search pattern. This should be used to avoid unwanted changes in the tools needed for making the app/dll.

ln -s bin/cygxxx.dll lib/[cyg|lib|]xxx.dll[.a]

Then you can link without any make environment changes.

gcc -Wl,-verbose -o a.exe -L../lib/ -lxxx

This technique also avoids the version number problems, because the following is perfectly legal

bin/ cygxxx-5.dll lib/ libxxx.dll.a -> ../bin/cygxxx-5.dll

Linking directly to a dll without using an import lib will work even when auto-import features are exercised, and even when -enable-runtime-pseudo-relocs is used.

Given the improvements in speed and memory usage, one might justifiably wonder why import libraries are used at all. There are two reasons:

1. Until recently, the link-directly-to-dll functionality did not work with auto-imported data.

2. Sometimes it is necessary to include pure static objects within the import library (which otherwise contains only bfd's for indirection symbols that point to the exports of a dll). Again, the import lib for the cygwin kernel makes use of this ability, and it is not possible to do this without an import lib.

So, import libs are not going away. But the ability to replace true import libs with a simple symbolic link to (or a copy of) a dll, in most cases, is a useful addition to the suite of tools binutils makes available to the win32 developer. Given the massive improvements in memory requirements during linking, storage requirements, and linking speed, we expect that many developers will soon begin to use this feature whenever possible.