libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Libtool woes


From: Jason Curl
Subject: Re: Libtool woes
Date: Mon, 20 Aug 2007 11:41:03 +0200
User-agent: Thunderbird 2.0.0.6 (Windows/20070728)

Brian Dessent wrote:
.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 - thanks for the concise description. Ralf - any way to may be add an addendum to the libtool docs for this, just for info?
Brian






reply via email to

[Prev in Thread] Current Thread [Next in Thread]