Libtool slaying

From ArchWiki

Jump to: navigation, search
Now that the results of operation Libtool-slay have been moved to current, users need to libtool-slay their own packages.
This page is the attempt to document the steps needed to successfully libtool-slay a package, based on an email by Damir Perisa.

Contents

What does libtool-slaying a package mean?

When building shared libraries (libfoo.so) using the GNU libtool, the .la files are being created automatically (libfoo.la). Libtool-slaying means removing the .la files from the package.
Adding !libtool to the 'options' array in the PKGBUILD will let makepkg handle the deletion of those files.
The older, manual way was to place the following line into the build() function of the PKGBUILD:

find $startdir/pkg -name '*.la' -exec rm {} \;

When do I need to libtool-slay a package?

You need to libtool-slay your own packages when they contain shared libraries that are being built with the help of libtool. While trying this you may uncover other packages that still have their .la files. In this case see next section.

Help, I'm getting strange errors!

Let's assume you are trying to build your package (fooapp) and encounter the following error:

grep: /usr/lib/libstdc++.la: No such file or directory
/bin/sed: can't read /usr/lib/libstdc++.la: No such file or directory
libtool: link: `/usr/lib/libstdc++.la' is not a valid libtool archive

Now obviously /usr/lib/libstdc++.la doesn't belong to fooapp, but it's also quite unlikely that gcc hasn't been slain already. Actually the error shows that gcc has been slain; the .la file is missing as expected. So who's to blame?

Finding the right package to slay

The error message about the missing libstdc++.la when compiling fooapp is the result of some package (a dependency of fooapp) containing outdated .la files. To find out which package this is, we have to find the offending .la file:

cd /usr/lib 
grep "libstdc++.la" *.la

This should result in something like this output:

somefile.la:dependency_libs='... ... ... /usr/lib/libstdc++.la ... ... ...'

Then you need to find out what package owns somefile.la:

pacman -Qo /usr/lib/somefile.la

This will tell you the package that includes the offending .la file. Now your next step is to update the PKGBUILD of that package to remove .la files at the end of the build function (see above). After that your original package should build again. In case it doesn't you have to find the next offending dependency and fix that first.

Warning: Some packages need their .la files!

Some packages, such as kde applications, need their .la files for module loading. Always test the functionality after slaying some libtool files! Other examples of packages that need their .la files are programs that depend on libtool. These packages use libtool functions to load libraries on runtime.

Personal tools