Linux vs Solaris - 编译软件答案

【问题标题】：Linux vs Solaris - Compiling softwareLinux vs Solaris - 编译软件
【发布时间】：2011-02-24 12:27:28
【问题描述】：

背景：

在工作中，我习惯于使用 Solaris 10。我们有系统管理员，他们知道自己在做什么，并且可以在需要时提供帮助。

我已经从源代码编译了 apache、perl 和 mod_perl 之类的东西，没有任何问题。

我得到了一个可以使用的 redhat 服务器，但我遇到了一些问题。系统管理员现在生病了。

我在构建软件时不断遇到关于 LD_LIBRARY_PATH 的问题。目前出于测试目的，我正在编译到我的主目录，因为我没有 root 权限，也没有在其他任何地方安装的权限。

我计划在 /opt 下有一个区域供我们安装，就像我们在 Solaris 上所做的那样，但我需要周围的系统管理员来为我们创建它。

我的 .bashrc 对 LD_LIBRARY_PATH 没有任何内容，因此我一直在向其添加内容以构建内容（例如来自源代码的 ffmpeg）。我一直在阅读这方面的内容，显然这不是要走的路，它不可靠或其他什么。我无权访问 ldconfig（权限被拒绝）。

现在是问题：

在 linux 下构建应用程序以使其不会崩溃的最佳方法是什么？在 /etc/ld.so.conf.d/ 下创建条目？

谁能简要概述一下 LD_LIBRARY_PATH 的实际作用？

【问题讨论】：

标签： linux compilation ld

【解决方案1】：

来自ld.so(8) 手册页：

  LD_LIBRARY_PATH
          A colon-separated list of directories in which to search for ELF
          libraries at execution-time.  Similar to  the  PATH  environment
          variable.

但老实说，找一个管理员。如果需要，就成为其中的一员。哦，还有构建包。

【讨论】：

从源码编译到前缀目录和创建包有什么区别？谢谢
包包含有关文件的元数据，可以在各种情况下使用，例如超级用户命令出错。此外，编译后的包可以放置在一个公共位置，并安装在所需的任意多个系统上，而无需在每个系统上重新编译。
这似乎是一个明智的前进方向。您会说以下文章对于以前从未这样做过的人来说是一个不错的教程吗？ ibm.com/developerworks/library/l-rpm1

【解决方案2】：

LD_LIBRARY_PATH 使单个用户或单个进程可以在细粒度的基础上向搜索路径添加位置。 /etc/ld.so.conf 应该用于系统范围的库路径设置，即部署您的应用程序。（更好的是，您可以将其打包为 rpm/deb 并通过您的发行版常用包渠道进行部署）

通常用户可能会使用LD_LIBRARY_PATH 来强制执行他们的程序以选择不同版本的库。通常这对于支持调试或检测版本的库很有用，但您也可以使用它将自己的代码注入到 3rd 方代码中。（有时也可能将其用于恶意目的，如果您可以更改某人的 bash 配置文件以诱骗他们执行您的代码，而没有意识到这一点）。

如果某些应用程序在非默认位置安装“私有”库，它们也会设置 LD_LIBRARY_PATH，也就是说，它们不会用于正常的动态链接但仍然存在。对于这样的场景，虽然我更倾向于dlopen() 和朋友。

【讨论】：

从源码编译到前缀目录和创建包有什么区别？谢谢
创建一个包通常有对库的依赖跟踪的规定（都由你的包提供并由它依赖）。如果两件事尝试提供相同的文件，它还提供冲突解决方案，并且它可以直接安装到 FHS 明智行为的默认路径，这可以完全避免设置任何异常路径的需要。

【解决方案3】：

设置 LD_LIBRARY_PATH 被认为是有害的，因为（除其他原因外）：

您的程序是根据您的LD_LIBRARY_PATH 动态链接的。这意味着它可以链接到特定版本的库，该版本恰好在您的LD_LIBRARY_PATH 中，例如/home/user/lib/libtheora.so。如果其他人试图在没有 yourLD_LIBRARY_PATH 的情况下运行它并最终链接到默认版本，例如在/usr/lib/libtheora.so。
它优先于任何默认系统链接路径使用。这意味着，如果你最终得到一个狡猾的 libc LD_LIBRARY_PATH，它最终可能会做坏事，比如泄露你的帐户。

正如 ignacio 所说，尽可能使用包。这避免了图书馆的噩梦。

【讨论】：