.dll.a 和.la 文件的作用

1. dll.a 其实是MinGW下的DLL文件的imp-lib (Import Library)

 

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

 

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

 

2. Building an Import Library (Reference)

Sun's distribution of the Java Development Kit includes a file in the lib/ directory calledjvm.lib. This is a Win32 static library against which compilers like VC++ can link. However,gcc can't handle the .lib file (as far as I know), so we need to create a UNIX-y import library (a.a file) against which we can link.

In order to do this, I tried to come up with the minimal set of JNI functions that need to be visible to native programs in order to link. I believe the following list of functions is minimal. Intuitively, it's because these are the only functions that can be called without having a reference to a pointer returned from one of these three functions:

• JNI_CreateJavaVM
• JNI_GetDefaultJavaVMInitArgs
• JNI_GetCreatedJavaVMs

Next, we'll create a DLL exports file to use with dlltool to build an import library. In order to do that, we'll export the symbols for the functions using the Pascal calling convention. (The numbers after the '@' sign indicate how many bytes need to be allocated on the stack for arguments.)

Here are the contents of the file:

EXPORTS
JNI_CreateJavaVM@12
JNI_GetDefaultJavaVMInitArgs@4
JNI_GetCreatedJavaVMs@12

By convention, DLL exports files are given the extension .def, so we'll save this file in our directory with the namejvm.def.

Now, we need to generate our import library. We can do that with dlltool, as follows:

dlltool --input-def jvm.def --kill-at --dllname jvm.dll --output-lib libjvm.dll.a

Naming the output file libjvm.dll.a will allow gcc to recognize it as a library named jvm. The .dll.a suffix indicates (by convention) that it is an import library, rather than a static library (which would simply be named libjvm.a, again by convention).

All of that said, I believe the libjvm.dll.a file would be standard across installations. So if you don't feel like building your own, you may be able to usemine. (If you try it, pleaselet me know whether it works.)

Note that in the dlltool argument list, we don't specify where jvm.dll is located, or which one we want to use. The name jvm.dll is what is embedded inlibjvm.dll.a (and hence in executables we will compile against it); no content fromjvm.dll is used. When a running program sees a reference to jvm.dll, it will attempt to locate it at that time. (Each Sun JVM has its ownjvm.dll, so we can take advantage of this feature to select which VM implementation to use at runtime.)

3. la 文件

原文地址：http://stackoverflow.com/questions/1238035/libtool-what-la-file-is-for

la file is textual file that includes description of library. It allows libtool create platform independent names. 即 la  文件是纯文本文件，只存放真实library的名字和路径。

For example, libfoo goes to:

Under linux:

/lib/libfoo.so       # symlink to shared object
/lib/libfoo.so.1     # symlink to shared object
/lib/libfoo.so.1.0.1 # shared object
/lib/libfoo.a        # static library
/lib/libfoo.la       # libtool library

Under cygwin:

/lib/libfoo.dll.a    # import library
/lib/libfoo.a        # static library
/lib/libfoo.la       # libtool library
/bin/cygfoo_1.dll    # dll

Under windows mingw:

/lib/libfoo.dll.a    # import library
/lib/libfoo.a        # static library
/lib/libfoo.la       # libtool library
/bin/foo_1.dll       # dll

So.. libfoo.la is the only file that preserved between platforms by libtool allowing to understand, what happens with:

• library dependencies
• actual file names
• library version and revision

Without depending on specific platform implementation of libraries.