对于那些从源代码编译过来的人来说，知道运行“./configure”只是为了找到那个X库还是丢失了多少痛苦，最糟糕的是它吐了一条愚蠢的行，说缺少一个神秘的lib文件，然后你必须在丢失的文件中找到一个网页浏览器类型，然后谷歌可以为你找到答案...
我觉得这很重复，所以我的问题是：
有没有办法解决所有必需的依赖关系，但没有做“./configure”
答案 0 :(得分：5)
阅读源代码发行版中的README *或INSTALL *文件（如果有），或者在您下载的网站上查找任何文档。如果包中有详细记录，则通常会在某处列出依赖项。
答案 1 :(得分：3)
鉴于没有提到具体的pkg，我认为这是一个通用的“如何避免使用configure”的问题。从源tarball，没有没有自动化的方法来处理依赖项。这就是配置的目的（你总是可以手动读取Makefile和autoconf文件并理解依赖关系，但是你很快就会错过配置）。为了避免它，你需要使用其他直接tarball，这已经解决了依赖关系。
例如，您可以切换到构建源rpms（或debs，取决于您的系统）。或者你可以使用像Gentoo这样的系统，它非常善于为你设计依赖项。但是所有这些都要求您感兴趣的pkg以其格式提供，因此它们不适用于您从源提供程序下载的tarball。
答案 2 :(得分：1)
阅读configure.ac / configure.in。查找对AC_CHECK_LIB，AC_CHECK_LIBS，AC_SEARCH_LIBS，AM_PATH_*的调用（一些不使用pkg-config的旧包将其检查放入AM_*由于某种原因，PKG_CHECK_MODULES（对于pkg-config），AX_*（编写了许多autoconf-archive宏以检查不常见的依赖关系）以及以奇怪名称开头的任何宏调用（即，不是AC_*，AM_*或AX_*。请尝试grep '^[^A]'？）。
答案 3 :(得分：0)
您可以做的一件事对社区有益，就是向软件包维护者提交错误报告/功能请求。有很多软件包的配置脚本不会在第一个缺少的依赖项上中止，但会运行完成，然后打印所有缺少的依赖项的摘要。这大大减少了你描述的单调乏味。不幸的是，“相当多”转化为低于.00001％（这是一个弥补统计数据）。如果您可以说服软件包维护者重新编写其配置脚本以支持此行为，那么您将有助于让世界变得更美好。
祝你好运！