这个问题包含一些误解，特别是在这里：
当我使用我的-L/dir2/lib标志来查找-lfoo时，由于libfoo.la文件期望foo被安装在/dir1/lib中，所以libbar编译/链接失败。
如果使用-L/dir2/lib -lfoo链接失败，那不是因为libfoo.la中的任何内容。 .la文件仅由libtool使用。它不参与其他方式进行的链接。实际上，可以完全删除它而不影响链接。如果/dir2/lib/libfoo.so是适当架构的共享库，并且在库搜索路径中没有libfoo.so或libfoo.a，那么-L/dir2/lib -lfoo选项将导致考虑共享库的标准Unix编译器或链接器尝试在链接中包含/dir2/lib/libfoo.so。
在问题中没有提供链接错误信息，而且这么长时间过后，我不指望会有任何补充。没有这些信息，就不清楚问题的实际性质是什么了。许多可能性中，最有可能的是：
- 该库是为错误的架构构建的（可能是x86与x86_64）。在这种情况下，需要从源代码构建适用于第二台机器的库版本。
- 安装在第二台机器上的库的所有权和权限不允许OP在那里构建。在这种情况下，应修复所有权和/或权限。
- 库具有未在第二台机器上正确满足的依赖项。在这种情况下，需要安装依赖项，并可能包含在链接中。
- 该库对其安装目录非常敏感。这在Linux上永远不会发生，但在某些其他类型的机器上可能会发生。在这种情况下，libtool可以使用.la文件将库放置在构建时指定的位置，但需要重新构建才能从不同位置使用。
- 实际上根本不是链接错误，而是涉及库的运行时失败。这可能是因为/dir2/lib/libfoo.so不在第二个系统的运行时库搜索路径中，或者因为它依赖于其他库。在基于ELF的系统上，libtool将在库中插入RPATH条目，但它们可能不适合不同的安装目录。它们甚至可能积极引起此类问题。适当更新动态链接器的配置可能有助于解决此问题。
我该如何避免这个问题呢？实际上，这并不是你想象中的那种问题。如果没有更多的信息，我只能提供一些一般性的建议：
使用Autotools构建系统时，请为正确的安装目录进行构建。不要假设结果可以重定位到不同的安装目录（尽管可能会）。不同的“机器”是可以的，如果足够相似，但不是不同的位置。但是，如果您希望最有可能能够重新定位安装，则应考虑使用诸如chrpath之类的工具从库中删除RPATH条目，甚至在构建时
黑客libtool以防止其首先添加一个。特别是如果您预计将库安装在其configure的位置之外。
确保配置系统的动态链接器在其搜索路径中具有安装目录。
如果更改安装路径，则删除已安装的.la文件，即使您没有更改安装路径也可能需要删除。
确保所有库的依赖项也已安装并在动态链接器的搜索路径中，并且它们实际上是兼容的。
所有这些都与RedHat的RPM打包准则一致，这些准则完全符合在一台机器上构建软件以供在另一台机器上安装和使用的情况。然而，并非所有内容都是必需的，尤其是关于RPATH的一些内容，还存在一些替代哲学。当您具有更多经验时，可以自由地忽略其中许多内容以及该主题上的任何其他建议。
.la文件。 - amaslenn