What Is an LA File? The Libtool Text File That Libtool Reads as Shell Code

7 How Do You Open an LA File? A text editor shows it, and libtool reads it when you link

The easy case is a text editor. Any editor on any system shows the 14 fields and the comments above them. The cat command prints them in a terminal. We found no program that edits LA files for you, and libtool writes new ones when you build a library.

We did not test Windows, Cygwin, MinGW or macOS. FileInfo lists only Libtool on Linux as software for the libtool type. The sections below cover editors, the command line, linking and loading.

In a text editor

1. 1 Open the .la file in any text editor. Use a code editor if you have one.
2. 2 Read the first four lines. They contain the words Generated by and the name and version of libtool.
3. 3 Read the fields. Every field has a comment above it that says what it stores.
4. 4 Close the LA file without saving, unless you mean to change it.

If you save an LA file, keep UTF-8 text without a byte order mark and keep LF line ends. In our tests, Windows line ends made libtool refuse the LA file, and a byte order mark made libtool print an error on the first line.

On the command line

The five commands below print the LA file, show its first four lines, name its type, hash it and use our script. The first four work on any Linux or macOS computer. Our 48 line script is the fifth command.

cat libfoo.la
head -4 libfoo.la
file libfoo.la
sha256sum libfoo.la
python3 la_peek.py libfoo.la

The file command prints libtool library file, ASCII text for a healthy file. It reads the type from the first comment line, so copies that lost the line printed only ASCII text.

Link a program against an LA file

The manual section on linking says that linking against an LA file lets libtool supply the library paths and the dependencies for you. We tried it. Libtool linked a test program against libfoo.la, and the program worked with no help from us.

libtool --mode=link gcc -o prog main.o /opt/lademo/lib/libfoo.la
readelf -d prog | grep -E "NEEDED|RUNPATH"

The program asked for libfoo.so.2 and recorded /opt/lademo/lib as its library search path. Both values came from the dlname and libdir fields of the LA file. The LA file named the library and the folder, and libtool did the rest.

Load a module with libltdl

The libltdl page of the manual says lt_dlopenext appends the .la ending first and a native ending next. That lets one program load both libtool modules and native libraries by one name.

We wrote a short C program that calls lt_dlopen. It opened libfoo.la by its full name and found a symbol. It refused 18 of our 50 damaged copies, and the damaged copies part shows which.

LA files that store lossless audio

FileInfo lists a second type for the .la ending, a lossless audio file. It names the La program and plugins for Winamp and foobar2000 as software. We tested none of them and found no audio LA file to test.

The file command 5.45 names two header versions of that audio type. When we wrote the bytes LA03 and LA04 at the start of two test files, it printed Lossless audio version 0.3 and version 0.4. Those were files we made ourselves, and they contain no audio.

If file says libtool library file or the first lines say Generated by, you have the libtool type, and this page applies. If the LA file starts with LA and then binary bytes, it is the audio type, and you need an audio tool.

How the readers did on our 50 damaged copies

8 How Do You Check an LA File? Six steps, and a 48 line script

The six steps

1. 1 Copy the LA file, write down its SHA256 hash and work on the copy.
2. 2 Read the first four lines with head -4 file.la. They must contain Generated by and the word libtool.
3. 3 Name the type with file file.la. You want libtool library file, ASCII text. Labels that show CRLF or UTF-8 (with BOM) point to an encoding problem.
4. 4 List the fields with grep -E "^[a-z_]+=" file.la. An installed file prints 14 lines.
5. 5 Use the script below. It reads the kind, the names and the folder. It also flags lines that are not comments or fields.
6. 6 Link a small test program in a scratch folder, or open the LA file in a second reader, and compare the answers.

A 48 line script that reads the LA file

The Python script below does steps 3 to 5 in under a second. It reads the LA file as text, checks the header and the quotes and tests the folder and the named files. It prints a kind and the main fields, and then a line for every problem. It changes no file.

#!/usr/bin/env python3
"""la_peek.py FILE.la  reads a libtool archive and executes none of it."""
import os, re, sys
QUOTED = 'dlname library_names old_library inherited_linker_flags dependency_libs weak_library_names dlopen dlpreopen libdir'.split()
BARE = 'current age revision installed shouldnotlink'.split()

def peek(path):
    raw, bad, v = open(path, 'rb').read(), [], {}
    if not raw: return ['empty file'], v
    if raw[:3] == b'\xef\xbb\xbf': bad.append('byte order mark at the start')
    if raw[:2] in (b'\xff\xfe', b'\xfe\xff'): bad.append('UTF-16 text')
    if b'\0' in raw: bad.append('NUL byte')
    if b'\r\n' in raw: bad.append('CRLF line endings')
    text = raw.decode('latin-1')
    if not re.search(r'^# Generated by .*libtool', '\n'.join(text.split('\n')[:4]), re.M):
        bad.append('no "Generated by libtool" line in the first 4 lines')
    for f in QUOTED + BARE:
        got = re.findall(r'^%s=(.*?)\r?$' % f, text, re.M)
        if not got: bad.append('missing field ' + f); continue
        if len(got) > 1: bad.append('%s is set %d times, the last one wins' % (f, len(got)))
        val = re.sub(r"(['\"])[ \t]+#.*$", r'\1', got[-1])  # some Nix files add #pruned
        if f in QUOTED:
            if len(val) < 2 or val[0] != val[-1] or val[0] not in '\'"': bad.append(f + ' has bad quotes'); continue
            val = val[1:-1]
        v[f] = val
    for i, line in enumerate(text.split('\n'), 1):
        if line.strip() and not re.match(r'(#|[a-z_]+=)', line) or re.search(r'\$\(|`', line): bad.append('line %d is not a comment or an assignment, or it has a command' % i)
    if v.get('installed') not in (None, 'yes', 'no'): bad.append('installed is not yes or no')
    for f in ('current', 'age', 'revision'):
        if v.get(f, '') and not v[f].isdigit(): bad.append(f + ' is not a number')
    ld, here = v.get('libdir'), os.path.dirname(os.path.abspath(path))
    if v.get('installed') == 'yes':
        if not ld or not os.path.isabs(ld) or not os.path.isdir(ld): bad.append('libdir is empty, relative or missing: %r' % ld)
    dirs = [d for d in (ld, here, here + '/.libs') if d and os.path.isdir(d)]
    for n in sorted(set(v.get('library_names', '').split() + v.get('old_library', '').split())):
        if not any(os.path.exists(os.path.join(d, n)) for d in dirs): bad.append('file not found: ' + n)
    bad += ['dependency not found: ' + x for x in v.get('dependency_libs', '').split() if x.endswith('.la') and not os.path.exists(x)]
    return bad, v

if __name__ == '__main__':
    bad, v = peek(sys.argv[1])
    if v:
        kind = ('loadable module' if v.get('shouldnotlink') == 'yes' else 'shared library' if v.get('dlname')
                else 'static library' if v.get('old_library') else 'empty shell')
        print('%s: %s, %s' % (os.path.basename(sys.argv[1]), kind, 'installed' if v.get('installed') == 'yes' else 'not installed'))
        for f in ('dlname', 'library_names', 'old_library', 'dependency_libs', 'libdir'): print('  %-16s %s' % (f, v.get(f, '?').strip() or '-'))
    for b in bad: print('  PROBLEM', b)
    sys.exit(1 if bad else 0)

On healthy files it prints the kind and the fields. On damaged copies it names the problem. It flags copy 5, with half the LA file cut, for ten missing fields and four missing library files. It names the folder problem in copy 28 and the encoding in copy 38.

python3 la_peek.py libfoo.la
libfoo.la: shared library, installed
  dlname           libfoo.so.2
  library_names    libfoo.so.2.1.2 libfoo.so.2 libfoo.so
  old_library      libfoo.a
  dependency_libs  -lm
  libdir           /opt/lademo/lib

python3 la_peek.py libbar.la
libbar.la: shared library, installed
  dlname           libbar.so.1
  library_names    libbar.so.1.0.0 libbar.so.1 libbar.so
  old_library      libbar.a
  dependency_libs  /opt/lademo/lib/libfoo.la -lm
  libdir           /opt/lademo/lib

python3 la_peek.py copy25.la
libfoo.la: shared library, installed
  dlname           libfoo.so.2
  library_names    libfoo.so.2.1.2 libfoo.so.2 libfoo.so
  old_library      libfoo.a
  dependency_libs  -lm
  libdir           /opt/lademo/lib
  PROBLEM no "Generated by libtool" line in the first 4 lines

python3 la_peek.py copy28.la
libfoo.la: shared library, installed
  dlname           libfoo.so.2
  library_names    libfoo.so.2.1.2 libfoo.so.2 libfoo.so
  old_library      libfoo.a
  dependency_libs  -lm
  libdir           /nonexistent/lib
  PROBLEM libdir is empty, relative or missing: '/nonexistent/lib'
  PROBLEM file not found: libfoo.a
  PROBLEM file not found: libfoo.so
  PROBLEM file not found: libfoo.so.2
  PROBLEM file not found: libfoo.so.2.1.2

python3 la_peek.py copy34.la
  libdir           /opt/lademo/lib
  PROBLEM installed is not yes or no

python3 la_peek.py copy38.la
  PROBLEM CRLF line endings

python3 la_peek.py copy49.la
  PROBLEM line 42 is not a comment or an assignment, or it has a command

What the script cannot see

The script reads structure and cannot say if the values are the ones you meant. It gave the same answer as for the healthy file on copies 27, 32, 41 and 47. Those copies lost the first line, emptied dlname, added an odd comment byte and switched to double quotes.

Flags are reasons to look closer and not verdicts. It flagged a healthy libconv.la that we copied without its archive folder. The script also looks only at the shape of lines, so commands hidden inside values are flagged only when they use $( or a backtick.

The script never executes the LA file. It does not decide whether a library is safe to link either, and it does not check that a named library file is the right one.

Want the causes of an error? Go to the causes.

9 Is an LA File Safe to Open? Reading is low risk, and linking executes the file

Reading an LA file in an editor is not the risk. The risk comes from tools that treat the LA file as code. In copy 40, libtool printed an error from its own script at the line that reads the LA file with the shell dot command. That shows how libtool reads it.

We scanned no LA file for malware, and we cannot say what packages you downloaded contain. What we can say is what an LA file can store and how our readers treated the added line.

What can ride inside an LA file

Who executed the added line

Dash and libtool executed the added line in copy 49. Libltdl and ImageMagick loaded the same file and did not, as our marker file showed. So linking a program is the step to treat with care, and loading a module through libltdl is not.

The reason is how every reader works. Libtool reads the LA file by sourcing it into a shell script, which executes every line. Libltdl has its own parser that looks for field names. We saw libtool 2.4.7 do this, and other versions or tools can differ.

Our script flags any line that is not a comment or a field, and any line that contains $( or a backtick. That catches the added line in copy 49 and a command hidden in a value. Read the LA file with your own eyes too.

What Debian says about LA files

Debian Policy, in section 10.2, says LA files for public shared libraries normally should not be in the package. Debian does not need them to link, and they can add needless dependencies to other programs. If an LA file is required, its dependency_libs field should normally be empty.

The same section says these rules do not apply to loadable modules. Debian's lintian tag marks a non empty dependency_libs field as an error. It says a filled field blocks the Multi-Arch conversion.

Our LA files agree. All 126 Ubuntu files have an empty dependency_libs field, and all 126 are modules. The 25 Nix files also have it empty, and 15 of them add the note #pruned.

Check before you link

1. 1 Hash the LA file and compare the hash with the package or the source, if the source lists one.
2. 2 Open the LA file in a text editor. The first four lines name libtool, and every other line is a comment or a field.
3. 3 Search for commands with grep -vE "^(#|[a-z_]+=|$)" file.la. A healthy file prints nothing. Commands hidden in field values pass this test, so read the values too.
4. 4 Use our script and read its last lines, the problems it lists.
5. 5 Link only when the libdir and the library names look like the package you expected.

If you ship an LA file of your own, read the policy of your distribution first. Debian wants most of them gone. If you keep one, follow Debian Policy and leave dependency_libs empty. Then check the file with our script.

11 How Do You Make or Remove an LA File? What libtool writes, and what Debian says to keep

Making an LA file differs from opening one. Libtool writes it, and no other program we found does. We built six libraries with Automake and libtool 2.4.7 to see what libtool writes. The 11 files we read came from the build folder and the install folder.

How libtool makes an LA file

1. 1 Compile every source file with libtool --mode=compile. It writes a .lo object file beside the object.
2. 2 Link the objects with libtool --mode=link and an output name that ends in .la. The link mode section says the build needs .lo objects and the -rpath option.
3. 3 Install the result with libtool --mode=install. The manual says the LA file records the install folder.

libtool --mode=compile gcc -c foo.c
libtool --mode=link gcc -o libfoo.la -rpath /opt/lademo/lib foo.lo -version-info 3:2:1
libtool --mode=install install -c libfoo.la /opt/lademo/lib/libfoo.la

We used these three steps by hand and also let Automake do the same work. Both gave an LA file in the build folder and an installed one. The install step set installed=yes and wrote our libdir.

The six LA files we built

Five of the six files are installed, and every one has a build copy as well. The convenience library is the exception, because it stays in the build folder.

Keep or remove LA files

Debian wants most LA files gone. the Debian section on libraries says a required file belongs in the development package, or in the runtime package when libltdl loads the library. It adds that an LA file that must stay should have an empty dependency_libs field.

We deleted no LA file to see what breaks, so we cannot say what a program does without one. If a program loads modules through libltdl, like ImageMagick, ask your distribution or the maintainer before you delete any of its LA files.

Convert an LA file to another format