Fine piece libtool updating doing

Avoiding libtool minefields when cross-compiling

If you've ever tried to cross-compile a free software project for a different architecture on GNU/Linux, you may well have run into the situation where you compile a library with your cross toolchain, install it in a “staging” directory that will hold your root filesystem (for example, you compile the library to go into , but you install it in , because that's where you're building your new root filesystem. You do this correctly: specify your when you , but provide when you ), and you try to compile another library that links against that library. Everything goes fine (the author of the program may have even written his configure script properly, so you can configure it to use the correct toolchain), but at the link step, you get this:

Now, why is the command trying to link against , which is your system's version of , and not ? You might play with compiler and linker flags, try to hack and understand the libtool shell script (best of luck if you can decipher it), and end up cursing the ancestors of those who ever came up with such a dumb system.

The problem turns out to be that and in this example both use libtool, and that the prefix happens to conflict with the system's library locations; when libtool installs a library, you'll see it installs .

What's with that file? You may, reasonably, expect to see one or two different kinds of library file: , which is just an archive of object files, and which you can statically link into your program; and , a dynamically loadable, sharable library. What's a ? Just one, and you'll see:

Notice the last line? It says that is installed in , so when libtool finds your in your temporary root filesystem tree, that file tells it to go look in . So, you have to prevent the libtool file from confusing the libtool script at link time.

You can probably just remove the libtool library file, and rely on your linker to figure out what you mean by (even though the strongly admonishes you not to delete it), but perhaps better is to just update in this file to point to where your library is temporarily installed. Using GNU sed you can do this:

I do this just after installing the cross-compiled library into my temporary root filesystem tree.

You likely won't need the libtool files any more when you install (if you're targeting an embedded Linux system), so you don't care if those files are correct once installed on the target. You'll probably just remove them from the final image, anyway.

I wrote this because I spent a long night of fighting libtool, Googling for help and finding none, and finally figuring this out. This is the second time I've even figured this out, having forgotten the solution the first time. Hopefully, this will help you out if you encounter this issue.

The wrong-gcc problem

For some packages, you seem to also run into trouble where libtool can't figure out what you're doing:

OK, so it couldn't figure out that we're compiling C code. No problem, just add the tag . Works when we compile:

But when we link, libtool tries to call the native gcc:

One rumored workaround (I haven't tried this, since I haven't had to cross compile anything in a while) is to specify a proper in :

Thanks to Waldemar Brodkorb for this workaround. Let me know if this works for you.

Another solution to this problem is to just install a cross libtool, which you'll use in preference to your system's libtool. It's easy enough to do; go grab the distribution, unpack it, and install it with:

Then, you can just use when cross compiling. That libtool (which is still just a shell script, so you needn't worry about running it on the host) will be set up properly for using your . You usually just have to add an environment variable when you your package.

Happy Hacking.

Copyright © 2007, 2009  Casey Marshall

This is the version of March 7, 2009.

This work is licensed under a Creative Commons Attribution 3.0 United States License.