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,
(*) |
before moving on to the next directory in the search path.
(*) Actually, this is not but in fact is <prefix>, 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 .
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/ lib/ (in case of dll's) (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 -L../bin/ -lxxx |
However, as the dll's often have version numbers appended to their names () 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/ lib/[cyg|lib|][.a] |
Then you can link without any make environment changes.
gcc -Wl,-verbose -o -L../lib/ -lxxx |
This technique also avoids the version number problems, because the following is perfectly legal
bin/ lib/ -> ../bin/ |
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.