Relative or independent paths in libtool .la file

Question

My .la file has full pathnames in both the dependency_libs= section and the libdir= section which makes it difficult to copy my libraries to a different machine (same arch but different path structure). What is the solution to this, besides having some script to hack the .la file to adjust for the paths on the new machine?

==Details==

When I ./configure; make; make install my libfoo, depending on how I use the --prefix, --exec-prefix, and DESTDIR= flags, I'll get an entry in the libfoo.la file that reads libdir=/dir1/lib and I'll have the actual .so files in the same dir as libfoo.la. All is well (in terms of linking something with libfoo as it is) until I package these up and put them on another machine.

Let's say I have libbar on my second machine which depends on libfoo. When I use my -L/dir2/lib flag to look for -lfoo, the libbar compilation/linking fails because of the libfoo.la file is expecting foo to be installed in /dir1/lib (from the first machine) when it's actually in /dir2/lib. I then need to replace all of the dir1's with the correct path, both of which can be long and complicated.

The dependency_libs= line also comes into play in a similar manner.

How do I avoid this problem?

Disseise

Did you try the staged installation method from the automake manual? – Glengarry

I did, that's why I mentioned the prefix and DESTDIR flags. All that can do for me is put my output in a certain directory... same problem though, the .la files will have an absolute path in them, so I run into problems when I move them around – Disseise

Have you found any solution for the issue? Except for hacking the .la files. – Gerrilee

This was years ago, but I do remember never finding a good solution :-\ – Disseise

Just stumbled upon this question and also still struggling with this here while cross compiling. Somehow it must be possible to supply a sysroot or something similar to libtool when doing make install right? This is so frustrating having to manually edit the .la dependency paths. Or is it a better practice to not use make install DESTDIR on the host machine to install libraries to a sysroot that you can later copy to the target? So many questions. :D – Poisoning

Answer 1

The question contains some misconceptions, especially here:

When I use my -L/dir2/lib flag to look for -lfoo, the libbar compilation/linking fails because of the libfoo.la file is expecting foo to be installed in /dir1/lib

If linking with -L/dir2/lib -lfoo fails, it is not because of anything in libfoo.la. The .la file is used only by libtool. It is not involved in linking performed by other means. In fact, it can be removed altogether without impacting linking. If /dir2/lib/libfoo.so is a shared library of the appropriate architecture, and there is otherwise no libfoo.so or libfoo.a in the library search path, then the -L/dir2/lib -lfoo options will cause a standard Unix compiler or linker that is considering shared libraries at all to attempt to include /dir2/lib/libfoo.so in the link.

No link error messages are presented in the question, and this long after the fact, I don't expect any to be added. Without them, it's unclear what the nature of the problem actually was. Among the more likely of the many possibilities are

• the library was built for the wrong architecture (presumably, x86 vs x86_64). In this case, a version of the library suitable for the second machine needs to be built from source.
• the ownership and permissions of the library, as installed on the second machine, did not permit the OP's builds there to read it. In this case, the ownership and / or permissions should be fixed.
• the library had dependencies that were not (correctly) satisfied on the second machine. In this case, the dependencies need to be installed, and probably included in the link, as well.
• the library was inherently sensitive to its installation directory. This is never the case on Linux, but it may be the case on some other kinds of machines. In this situation, libtool can use the .la file to put the library in the location specified for it at build time, but it would need to be rebuilt to be usable from a different location.
• it was never a link error at all, but rather a runtime failure involving the library. This might happen because /dir2/lib/libfoo.so is not in the second system's runtime library search path, or because it depends on other libraries that are not. On an ELF-based system, libtool will have inserted RPATH entries into the library, but they are likely to not be appropriate for a different installation directory. They might even actively cause such an issue. Updating the dynamic linker's configuration appropriately might help in this situation.

How do I avoid this problem?

It's not the problem you think it is, and without more information, I can offer only general advice:

1. When using an Autotools build system, build for the correct installation directory. Don't assume that the result will be relocatable to a different installation directory (though it might be). A different machine, yes, if sufficiently alike, but not a different location. But if you want the best chance of being able to relocate the installation, then

2. Consider using a tool such as chrpath to remove the RPATH entry from the library, or even hacking libtool at build time to prevent it from adding one in the first place. Especially if you anticipate installing the library other than in its configured location.

3. Be sure to configure the system's dynamic linker to have the installation directory in its search path.

4. Remove the installed .la file if you are changing the installation path, and maybe even if you aren't.

5. Ensure that all the library's dependencies are also installed and in the dynamic linker's search path, and that they are actually compatible.

All of that is consistent with RedHat's RPM packaging guidelines, which cater to exactly the case of building software on one machine for installation and use on another. It is not all absolutely required, however, and there are alternative philosophies about some of that stuff, especially RPATH. When you have more experience, feel free to ignore as much of that and any other advice on the topic as you like.

Terpsichorean