What Are Libtool's .La File For

What are libtool's .la file for?

It is a textual file that includes a description of the library.

It allows libtool to create platform-independent names.

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 is preserved between platforms by libtool allowing to understand what happens with:

• Library dependencies
• Actual file names
• Library version and revision

Without depending on a specific platform implementation of libraries.

What is libtool's .lai file for?

.lai is the extension of a file that will be installed as an .la file. In other words, i is appended in order to show that it is in a temporary "staging" state.

What the i stands for is anyone's guess. My guess is that it has something to do with "install".

libtool: convert/extract la to a

that in the .libs subdirectory should be .a libfile, but I've found there only .la, .so, and .o files, probably because the lib project was not configured with --enable-static.

That's what it sounds like to me as well. You'll need to do that to get a .a file. The libs you are building with libtool are probably being compiled with gcc.

Is it possible to convert or maybe extract a file from .la library to .a?

No. There's no object code in a .la file to extract to a .a file. As the link to the other answer says, it's basically a metadata file of how to link and where the files are, etc. A .la file is humanly readable, so if you really want to know what's going in there you can examine it.

How to install and use libtool shared library (.lo files)?

From the outputs mentioned in the question, it looks like you ran libtool with --mode=compile mode. You will need to run libtool again with --mode=link to produce .a and .so libraries.

libtool is just a simple wrapper for gcc, ln ar and ranlib which is needed to produce libraries. All it does is run gcc adding the necessary options to ensure that your static and shared libraries are created correctly.

When compiling libtool inserts the -fPIC tag to ensure the necessary generation of position independent code needed for shared libraries. The .o files are normal object files that can be archived into a static .a file. The .lo files are object files with position independent code which can now be linked into a .so file.

When linking libtool will run ar to create a static library or ln to link the objects files into a .so shared library.

libtool also can install the library when desired using the --mode=install.

See http://www.gnu.org/software/libtool/manual/libtool.html for more info.

Please remember that when building an executable there are always two stages, compiling and linking.

Static linking with libtool, without modifying dependency_libs in .la file

Here's the best solution we've found, for posterity:

It seems there's no very neat way to get this to work. The nicest I've found is to avoid -L and -l flags when "internally" linking like this, and instead to directly put $(builddir)/extralib/libmy-secret-lib.a in the LDFLAGS/LIBADD variable for the final shared lib.

This unfortunately produces a libtool warning about non-portability and the need to build the "hand-made convenience lib" with -fPIC -- even it has been built that way and is fully portable. ...LIBTOOLFLAGS = --silent isn't enough to hide that cry-wolf warning, sadly, but the result is good: required symbols copied into the final library, dependency_libs unsullied, and no hacks (like this: https://gitorious.org/libguestfs/libguestfs/source/c46bedf925cd9c6c9a9cbaee115358fd1dffcbfe:libtool-kill-dependency_libs.sh) required.

How do I link against libtool static la library?

The libtool .la is a 'meta data' file. After building the cds2 library, it's expected that libtool will also be used in 'link' mode to build any of the package's tests, etc.

Typically, the in the directory you find the .la file, you will find the .a and .so under the .libs subdirectory. The .libs/libcds2.a file will be found there, provided configure was given the --enable-static option (or it is enabled by default). But, my understanding is that you've installed the package in /opt :

g++ -I/opt/include/ libcdsNoptrs.cpp util.cpp -o test /opt/lib/libcds2.a

Otherwise, if libcds2 isn't installed, just supply a path to: .../libcds2/lib/.libs/libcds2.a

Unless you want to use libtool in --link mode with -static to handle everything. But learning the advantages of libtool is usually an exercise for a rainy day:)

---

Related Topics