问题标签 [libtool]

我正在运行 Linux，Ubuntu 10.04。

这不是我第一次尝试使用自动工具。我做了很多研究并遵循了很多教程：这是我想做的，我尝试过的以及我面临的问题。

目标：

• 编译（然后交叉编译，但这将是另一项工作）我自己的库，使用 libtool、autoconf 和 automake 用 C 编码

我尝试了什么以及我在哪里：

• 库名称为 FXPLib，包名称为 libfxplib-0.1

• 我的项目文件夹是：

  /li>

• 我运行了自动扫描，得到了一个 configure.ac，在这里进行了编辑：

  /li>

• 我这样写 Makefile.am ：

  /li>
• 然后我运行aclocal和autoheader来获取 automake 需要的文件
• 然后最重要的：autoconf
• 并且：automake --add-missing --copy

从那里开始，一切都很好。但后来我尝试编译：

一切都还好...

然后我得到：

在哪里 ：

• "graphics_engine"相当于src/ sub
• “FXP_rendering.c”到src/sub/ file.c
• “FXP_image_s.h”到src/sub2/ header.h

这意味着：automake 可以编译子目录中的 .c 文件，但不能在这些文件中包含位于其他子目录中的私有 .h 文件。

我的问题是：如何告诉 automake 编译每个子目录中的每个文件，就好像它们都在同一个地方一样？

我希望我是可以理解的（对于您在我的话中发现的一些问题，我很抱歉，因为我是法国人）

提前谢谢你。

我Makfile正在使用libtool以创建一些 apache 模块。

不幸的是，我需要我的 makefile 在 VMWare 共享 forlder ( hgfs) 上工作，它不支持任何类型的链接（符号链接或硬链接）。

我可以使用libtool并使用它cp来代替ln -s，而不修补LN_ST脚本中的变量，从而破坏libtool系统的其余部分，同时防止将来升级到libtool？

我遇到的问题解决了。我发布此内容是为了就解决方案实际有效的原因寻求解释。我以前在这里得到了很好的反馈。

我有一个使用非常简单的构建系统的遗留代码库，我的项目是将其迁移到 Autotools 以进行定制，特别是构建共享库。主库是用 C 编写的，但也必须可从 Fortran 链接（用于遗留目的），并且在 F77 中与一些测试代码一起分发。作者将源代码组织成模块...

他们lib/libmain.a通过编译 src_*/ 目录中的代码并使用 ranlib 归档对象来构建库。

我的第一种方法是分别从每个 src_*/ 构建一个共享库，并将所有这些“链接”到一个共享库中。使用 Autotools，src_module1/Makefile.am将包含

其他模块依此类推，最后lib/Makefile.am只需要：

这似乎工作得很好。但是，当 testc/ 中的代码被编译并链接到 libmain.la 时，会发出“未找到符号”错误。

认为这是 libtool 或共享库的问题，我尝试仅构建静态，基本上将全部.la更改为. 同样的问题。然而，这一次，在尝试链接 libmain.a 本身时，注意到错误“ranlib：库警告：libmain.a 目录为空（库中没有目标文件成员定义全局符号）”。.a_LTLIBRARIES_LIBRARIES

我发现的解决方案似乎是一个 hack。我没有为任何 src_*/ 目录构建 Makefile，而是仅用于 lib/ 目录，它的 Makefile.am 有以下行：

这行得通。testc/ 中的已编译程序与 libmain.la 链接没有问题。其中一个“模块”是一组 Fortran 绑定，它们将库中的其他 C 函数包装起来。甚至 testf77/ 中的 Fortran 代码也正确链接到 libmain.la。

有人可以仔细解释 libtool 构建共享库时会发生什么吗？甚至在构建静态库时？为什么不能将几个静态库链接在一起组成一个静态库？为什么只有当 libtool/ranlib “从源代码”构建库时符号才可用？那么安装一个共享/静态库呢，即将它移动到 /usr/local/lib --- 那里会发生什么？关于静态和共享库的 Wikipedia 文章对我来说还不够详细。

我非常感谢为理解我冗长的问题所做的一切努力。

我在我的 C 代码中使用 libltdl 来动态加载 libtool 制作的共享对象文件。显然，libtool 的 dlopen 版本返回的每个模块句柄都在内部保留了一个引用计数。有没有办法访问这个引用计数？

您好我正在开发一个 C libtool 库。我在添加依赖库 xml2 时遇到问题。我决定使用 GNU autotools，蝙蝠我很新手。

在 configure.ac 我有：

在 MakeFile.ac 中：

正确配置脚本输出：

在生成的 Makefile 中有：

当我启动 Make 时：

make 命令没有链接 libxml2，任何人都可以帮助我吗？

尝试编译 libptrace ( http://sourceforge.net/projects/libptrace/ )。该项目没有宣传任何请求支持的首选方式（不幸的是，该项目没有指出获得帮助的最佳方式）。Anywho，我遇到的问题如下：

如果你用谷歌搜索 libptrace 和 libgnu.la，你会得到零命中。在源代码中寻找它，从 git 中取出新鲜的，你会得到：

我不知道如何生成 libtool 存档文件，并且 source 似乎没有任何 make 目标或脚本，否则会这样做。

关于管理员的注释：请在这个问题中添加标签“libptrace”——显然是一个非常受欢迎的话题——我不能这样做，因为我没有达到 1.5K 点数:(

针对 Mel 对 build.sh 的修改，以下是在 `make' 上生成的新错误：

我正在尝试将基于 libtool 的包合并到我自己的项目中，可能是以非标准方式。这是我的目标：

1. 构建外部项目：

   /li>

2. 在运行时构建我自己的项目，该项目依赖于外部项目的共享库和可执行文件：

   /li>

3. 将所有内容打包成一个“本地化”压缩包......也就是说，虽然我在$HOME/blah构建主机上拥有所有内容，但我希望能够将压缩包解压缩到任何任意目录（在其他主机上），而不必与我的环境混为一谈。目的是允许我的项目的多个版本并排共存，而不会出现任何令人讨厌的“异花授粉”。

我知道我可以-rpath '$ORIGIN/../lib'在我的项目中使用它来确保始终在运行时加载正确的共享库。但是，似乎 libtool 坚持-rpath根据 的确切路径分配自己的设置$HOME/blah/lib，如果我碰巧将所有内容解压缩到不同的目录（例如，$HOME/blah.2011-06-02），则会中断。

有没有办法绕过这个限制？我看到debian 和 libtool 人员之间就该主题进行了相当冗长的 rpath 讨论，但除了“我们不同意”之外，它有些陈旧且不确定。

当我在带有 autotools 和 libtool 的项目中运行“make”时，该库已正确构建，但未在其路径中创建可执行文件。这是 automake 生成的行：

此行不打印任何内容（甚至是错误）。这个 Makefile.am 有问题吗？

我正在尝试使用 mipsel-angstrom-linux 工具链在我的 Ubuntu 10.10 开发机器上交叉编译 openldap-2.4.23，因为它是 ptlib-2.10.1/opal-3.10.1 的依赖项，这些库实际上是我的库想用。

我已经设置了一个build.sh脚本，其内容如下所示。它

构建工作但中止以下内容：

我也遇到了其他库的问题，添加LIBTOOL=libtool曾经能够解决问题。我也尝试mipsel-angstrom-linux-libtool按照其他资源的建议编译我自己的，但没有奏效。

我grep libz -r .在源代码/构建目录中做了一个但找不到任何东西，我不知道在哪里看。

我希望有人能给我一个提示，让我解决我的问题。

编辑：使用我得到的 codesourcery 工具链result.c:961: undefined reference to lutil_memcmp'。

I'm trying to create an RPM of my package, which is built using automake and libtool, and I've encountered a problem: rpmbuild aborts upon discovering that the installed programs of the package contain the pathname of the installation directory for the package's sharable libraries (due to automake's use of the -rpath option of ld).

I understand that rpmbuild does this in order to guarantee that the package is relocatable. My question is what to do about it. I could eliminate the use of sharable libraries (and lose their benefits) or I could tell automake to not install the sharable libraries (which would stop it from using the -rpath option) and then install them anyway. The cost of this latter option is that it would require that the user always have a correctly-set LD_LIBRARY_PATH environment variable -- plus it seems like a bit of a kludge.

Is there another option?

What would you do?