libNAME.lib or NAME.lib?



F. Kater writes:
I am a bit confused by different working libraries when I download the
precompiled packages (I am working with mingw32):

* glib.lib (with corresponding glib-2.0.dll)
* libglib.lib (with corresponding libglib-2.0.0.dll)

I don't know where you have found such files, and why you try to use
them with gcc.

Firstly, import libraries for gcc (mingw32) are typically called
libfoo.dll.a or libfoo.a, not foo.lib. foo.lib is for MSVC. (Well, the
GNU linker knows how to read .lib files, too, but it looks for
libfoo.dll.a and libfoo.a first, as far as I know. GNU libtool does
not know to look for foo.lib files.) The corresponding DLL, if
produced by libtool, would then be libfoo-X.dll, where "X" is a number
corresponding to the "current interface number minus the interface
age". This can be pretty obscure, yeah.

Secondly, the libraries for glib have "-2.0" as part of the "basename"
("foo" in the example above would be "glib-2.0", "gobject-2.0"
etc). This comes straight from their Makefiles etc. On Unix the shared
library for glib is called something like libglib-2.0.so. (For this
discussion, ignore the detail that this is actually a symlink to
libglib-2.0.so.x.y.z.) The "-2.0" part is not some versioning
metasyntax that would have been tacked on by libtool or some other
tool, but an integral part of the library's name.

I.e. the GLib import library for gcc (mingw) is libglib-2.0.dll.a, and
for MSVC it's glib-2.0.lib.

Thirdly, the GLib DLL I distribute is called libglib-2.0-0.dll. What
glib-2.0.dll and libglib-2.0.0.dll are I have no idea. They might be
binary compatible with my builds, or not.

* gnet.lib (with gnet-2.0.dll)
* libgnet.lib (with libgnet-2.0.0.dll)

Well, presumably these naming convention depends on what tools their
distributor uses to build the packages, their policies, and what
deliberate or accidental choices they have made.

What library should I use? Both seem to be working.
Is there a somewhat "change" in naming libraries from "XXX.lib" to
"libXXX.lib"?

My opinion is that for MSVC import libraries, the "lib" prefix is
unnatural, so XXX.lib. For a Unix-style linker, the "lib" prefix is
the 30 year old convention, so libXXX.a or libXXX.dll.a is the right
name. libXXX.lib is a mix of two conventions, and should be avoided.

Of course, some packages might have "lib" as part of their "basename",
so this can get confusing... Add the fact that they might have
established DLL and import library names decreed by the author, that
don't necessarily correspond to any convention, and one can get pretty
confused...

--tml





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