问题标签 [libtool]

似乎使用 libtool 只会让它变得更复杂，为什么不坚持使用 gcc 呢？

在尝试使用 gdb 为使用 libtool 构建的包调试测试程序时，我看到了一个奇怪的问题。如果我运行libtool --mode=execute gdb .libs/libfoo.so并要求它列出某个函数list Bar::Baz的源代码，我会按预期获得源代码。如果我运行libtool --mode=execute gdb binary，我可以闯入Bar::Baz()，并在堆栈跟踪中查看它的参数，但我没有得到源文件或行号，如下所示：

list Bar::Baz同样，如果我在调试可执行文件时尝试，我会得到

我已经确认二进制文件与 链接-g，并且我可以列出它的main功能，所以我知道存在一些调试信息。

当我说 时info sources，我得到了构建库的文件的完整列表，以及正确的绝对路径。当我说 时info shared，我得到了目标文件的正确路径，列中有Yes一个Syms。

任何进一步的想法可能会出现什么问题，以及如何解决它？

编辑 1： 意外地，我在objdump -g有问题的库上运行，并得到以下输出：

这令人惊讶，因为objdump -h（我试图运行的）列出了一堆.debug_*部分。该objdump手册也提出readelf -w了建议，这似乎打印了大量信息。不过，我需要查看它实际提供的功能。

编辑2：所以，readelf -w产生了一些启示。无论出于何种原因，共享对象文件似乎都不包含来自绝大多数 链接到它的任何对象的调试信息。根据 Makefile，实际将对象收集到共享库中的命令可能未通过-g，因此信息未正确传播。有趣的是，这在我们所有其他配置上都有效（具有完整的调试信息），包括 x86_64 上的相同编译器版本（相对于目前的 x86）。

编辑 3：实际上通过在 LDFLAGS 上添加了 -g 的修改后的 Makefile 进行了完全重建，并且没有任何区别。现在我很好，真的很困惑。

我正在尝试在 linux 机器上交叉编译 ImageMagick。工具链自带的 libstdc++.a 不是用 fPIC 编译的。我想改用so文件。但是 libtool 不断链接 libstdc++.a （作为整个档案），我得到重定位错误。我在其他图书馆也看到了同样的问题。有任何想法吗？

如何--as-needed使用 Automake 链接共享库？当我尝试将标志添加到 时LDFLAGS，我看到libtool这样调用：

这会导致像这样调用 GCC：

但这是错误的顺序。

• 有没有办法用 Libtool 做到这一点？

• 或者有没有一种使用 Automake 但没有 Libtool 来构建共​​享库的好方法？（过去，由于其他各种原因，我一直对 Libtool 感到沮丧……）

似乎 Debian 的人也遇到了这个问题（错误报告），但我希望能够为我的项目解决这个问题，而不是弄乱我的系统（除非我误解了修复）。

如何使用 autotools/libtool 构建和安装 .so 模块，而无需将 .la 和 .a 库也安装到 --prefix 路径中？

目前我正在使用以下 Makefile.am：

它可以工作，但除了 libCurlDownloader.so 之外，它还安装了 libCurlDownloader.la 和 libCurlDownloader.a，这是不可取的。

更新#1

可以使 .a 不生成，通过使用

或者

在configure.ac

但这仍然是一个问题，如何在安装 .so 时不将 .la 安装到安装 --prefix 中。

更新#2

可以从安装中删除 .la 文件 --prefix 使用

我正在尝试用 c++ 编写一个跨平台程序，该程序将在运行时加载某些模块（共享库）。为此，我使用了Poco C++ Libraries中的 ClassLoader 。我使用 autoconf、automake 和 libtool 编写了一个编译链。这在 Linux 环境中应该没有问题，但是在 Windows 中会出现问题。我在编译时使用了 MinGW 和 MSYS，以便能够使用我的 Makefile。ClassLoader 使用 Windows 特定的 LoadLibrary() 函数来加载模块，这意味着我必须将它们编译为 DLL。

我编译到库中的类继承了主应用程序中的另一个类。然后，当我尝试运行 make 时，它​​会抱怨很多未定义的引用并拒绝构建共享库。我想这是因为名字修饰。还是因为我不能继承库之外的类？（该类不包含在库的源代码中，但找到了头文件）

我不太确定我坚持在 MinGW + MSYS 下编译但仍然使用 LoadLibrary() 会带来多少麻烦。有这方面经验的人吗？

我手头有一个项目，其中一些库被编译为可加载模块，即与 libtool 的-module标志链接。这些库本身或它们的依赖项应该包含所有必要的函数，也就是说，当与一个简单的 main() 函数链接时，它们应该产生一个完整的程序，该函数只是为我的程序调用模块接口的所有函数。

由于我之前遇到过不完整且因此无法使用的模块的问题，因此我有一些简单的检查程序，它们只包含一个 main() 并与模块链接。当一个函数丢失时，链接器会发出适当的警告，所以一切都很好。但是，libtool 给了我一个警告：

我了解此警告的目的和意图（不要将程序与使用 构建的库链接-module），但不了解其严重性，这是我的问题：

这个警告有多严重？我很幸运，这适用于我正在编译的平台（i386/x86_64 Linux 和 MinGW），还是这个警告只与一些我可以安全忽略的晦涩的落后平台相关？

我想在不同的 Debian/Ubuntu 版本上构建一个与 Debian Lenny （libc、postgres、oracle 和其他库）兼容的应用程序。这可能吗？如果是这样，我在哪里可以阅读如何做到这一点？

我正在尝试在我的 Ubuntu 11.10 服务器上安装 PCRE。当我运行“make”命令时，我得到一个很长的输出，总是以这个错误结束：

我确实运行了“配置”。有任何想法吗？

在Autotools: A Practioner's Guide to GNU Autoconf, Automake, and Libtool一书中，第 6 章（使用 libtool 构建库）中给出了链接库的示例。

在示例中，一个库libjupiter.so链接到另一个库libjupcommon.a。第一次尝试失败，因为libjupiter.so需要 PIC，但libjupcommon.a不是。作者添加libjupcommon_a_CFLAGS = -fPIC以修复它。它变得更好了，但是'将共享库 libjupiter.la 与静态库 ../common/libjupcommon.a 链接起来的警告不可移植！'出现。

因此作者再次修改了 Makefile.am 的，使用 libtool 来构建libjupcommon.la。的libjupiter链接libjupcommon.la。像这样：

noinst_LTLIBRARIES = libjupcommon.la

libjupcommon_la_SOURCES = jupcommon.h print.c

和

...

libjupiter_la_LIBADD = ../common/libjupcommon.la

这次一切正常。

现在，我的问题：

我有一个图书馆需要另一个图书馆，就像libjupiter需要一样libjupcommon。不同之处在于我libjupcommon来自另一个项目并安装到系统中。它不是一个noinst_LTLIBRARIES. .so和.a版本都存在。当我尝试链接libjupcommon.la示例显示的内容时，.so选择了 ，但我不想要动态链接关系。我想链接到.a，就像书中的例子一样。

显式链接.a（通过使用 _LIBADD=.a 文件）提供了一个可用的库，但给出了“...不可移植”的警告。

.a在这种情况下实现链接的正确方法是什么？

PS：从本书的官方网站下载示例。在autotools/book/jupiter-libtool-ch6/common中，将 Makefile.am 修改noinst_LTLIBRARIES为lib_LTLIBRARIES应该与我的问题非常相似。