Jason Curl wrote: > I guess what happens if I don't say this the build will fail. I've
It should produce static libraries if it cannot produce shared ones. > turned it on and it looks good. I'll try and search more info later, but > while I'm at it: > - Why is it .dll.a and not .dll? > - How is versioning information embedded in the DLL, or is the basis of > the DLL hell? .dll.a is the import library. .dll is the actual library. Both should be produced. The import library is used when linking against the library, but it is not needed at runtime and contains no code. It's typically distributed in the same context as headers -- it is needed by developers who want to build against your library, but not users who simply want to run software that uses your library. In some cases it is also named just "libfoo.a", or perhaps "foo.lib" if you want compatibility with users of the MS toolchain. As its name suggests this is actaully an "ar" archive. It looks like you may be getting confused because the linker outputs a message along the lines of "creating file libfoo.dll.a" when the --out-implib linker switch is used, but this really means "in addition to the normal output libfoo.dll I'm also producing an import library libfoo.dll.a as a side effect of creating the library" not that the library would actually be named libfoo.dll.a. The concept of an import library is a bit of a hold-back to days past. Using the GNU linker at least, you can link directly to a DLL without any import library. However, there is one function of an import library that cannot be duplicated otherwise, and that is the ability to provide aliases for symbol names. This allows you to do things like rename functions in the actual library without affecting callers/users that use the old name. It also comes in very handy when reconciling differences in stdcall function decoration when trying to mix code between different vendors' toolchains. PE has no means of explicit symbol versioning. Shared library versioning works on the basis of choosing an appropriate filename for the library, i.e. libfoo-n.dll. This should happen automatically when you use -version-info appropriately. The import library thus also provides one further function that makes it very handy -- it functions analogously to the "foo.so -> foo.so.1" symlink on POSIX systems. The import library is always named just libfoo.dll.a without any version numbers, and so the linker finds it when you specify -lfoo. However, the actual name of the library may be libfoo-2.dll (or cygfoo-2.dll if you're using Cygwin) and hence the import library is the thing that selects which version of the library to link against. For example on Cygwin: $ ls -l /usr/bin/cygintl* /usr/lib/libintl* -rwxr-x---+ 1 brian Users 22K Dec 13 2001 /usr/bin/cygintl-1.dll -rwxr-x---+ 1 brian Users 37K Aug 10 2003 /usr/bin/cygintl-2.dll -rwxr-x---+ 1 brian Users 31K Nov 19 2005 /usr/bin/cygintl-3.dll -rwxr-x---+ 1 brian Users 31K Oct 22 2006 /usr/bin/cygintl-8.dll -rwxr-x---+ 1 brian Users 48K Oct 22 2006 /usr/lib/libintl.a -rwxr-x---+ 1 brian Users 30K Oct 22 2006 /usr/lib/libintl.dll.a -rwxr-x---+ 1 brian Users 800 Oct 22 2006 /usr/lib/libintl.la Here you see that there are four versions of the libintl library installed, however there is just the one import library. The name of the DLL is encoded into the import library, so this means any new code that is compiled today with -lintl will find /usr/lib/libintl.dll.a which internally specifies the filename corresponding to ABI version 8 of the library. But the other versions can still exist on disk for the sake of supporting existing binary packages of the previous ABI versions. So this works just like the symlink on POSIX that selects which version of the library all new binaries should link against (which is almost always the newest.) Brian _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
