制作 os 独立的配置文件来检查 curl 依赖性
Making os independent configure file which checks for curl dependency
我正在制作一个 configure.ac 文件来检查库依赖性。
完整的代码是，
AC_CONFIG_AUX_DIR([build-aux])
AC_INIT([myprogram], [0.1], [])
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_CHECK_LIB([curl], [curl_easy_setopt], [echo "libcurl library is present" > /dev/tty], [echo "libcurl library is not present" > /dev/tty] )
AC_CHECK_LIB([sqlite3], [sqlite3_open], [echo "sqlite3 library is present" > /dev/tty], [echo "sqlite library is not present" > /dev/tty] )
AC_CHECK_LIB([pthread], [pthread_create], [echo "pthread library is present" > /dev/tty], [echo "pthread library is not present" > /dev/tty] )
AC_CHECK_LIB([crypto], [SHA256], [echo "crypto library is present" > /dev/tty], [echo "crypto library is not present" > /dev/tty] )
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
"myprogram"是一个需要安装在众多用户pcs.So中的程序，开始时需要做依赖检查，看是否是这四个库已安装。
在 /usr/lib/i386-linux-gnu/libcurl.so 所在的系统中，当我 运行 配置文件时，它给出消息 "libcurl library is present"。但是，在存在 /usr/lib/i386-linux-gnu/libcurl.so.1.0 或类似内容的系统中，这表明 libcurl 不存在。如果我创建一个软 link 到 libcurl.so ，那么它正确地告诉 libcurl 存在。
ln -s /usr/lib/i386-linux-gnu/libcurl.so.1.0.0 /usr/lib/i386-linux-gnu/libcurl.so.Same 也适用于其他库。
实际上，我想使这个过程自动化。有没有办法做到这一点，而无需手动制作软 link？我的意思是，通过对 configure.ac 文件本身进行更改，这样配置将 运行 在没有需要制作软 link.
在安装库时，安装程序通常会创建一个符号 link 从库的真实名称 (libcurl.so.1.0.0) 到它的 linker 名称 (libcurl.so) 允许 linker 找到实际的库 file.But 它并不总是 true.Sometimes 它不会创建 linker name.That 是为什么这些并发症是 happening.So 检查 linker 名称的程序认为没有安装库。
In systems where, /usr/lib/i386-linux-gnu/libcurl.so is there, it is giving the message "libcurl library is present", when I run the configure file. But, in the systems where /usr/lib/i386-linux-gnu/libcurl.so.1.0 or something similar is present, it is telling that libcurl is not present.
是的，这是我所期望的行为。这里发生的事情是，AC_CHECK_LIB 发出一个带有你给它的符号的程序，然后 link（在本例中为 curl_easy_setopt），执行编译步骤和 link确保 link 人可以 link 的步骤。在典型的 Linux 发行版上，您需要确保安装了一些名为 libcurl-dev（或类似的东西）的软件包，因此您将拥有头文件和 libcurl.so sym link 已安装。
But I want to automate this process. Is there a way to do this, without manually making a soft link?
libcurl-dev 包的安装可以轻松实现自动化。它可以通过多种方式完成，具体取决于您想要的方式。 Linux 打包系统（例如 rpmbuild、debhelper 等）如果未安装，可以在构建之前引入构建依赖项。您用来设置构建机器的配置管理工具（例如 ansible、SaltStack 等）可以安装它。依赖项应至少列在发布文档中，以便如果无法访问这些工具（或不关心使用它们）的人可以弄清楚并构建。
我不会在 configure.ac 中创建 symlink -- 它可能会破坏 libcurl-dev 的任何未来安装。此外，您将 拥有 到 运行 configure 的提升权限（例如 sudo）来创建 link.
While installing a library, the installer program will typically create a symbolic link from the library's real name(libcurl.so.1.0.0) to its linker name(libcurl.so) to allow the linker to find the actual library file.But it is not always true.
实际上，我不记得见过这样的事情。通常，当 DSO 安装到 ldconfig "trusted directories"（例如 /usr/lib 等）时，ldconfig 会得到 运行，因此真正的库（例如 libcurl.so.1.0. 0) 在同一目录下得到一个symlink (libcurl.so.1)，但不是开发symlink (libcurl.so).
编辑：添加对评论的回复
But why ./configure also expects development symlink s(libcurl.so, libcrypto.so etc)
因为 configure 可以告诉 运行 那个 link 人，正如你在 AC_CHECK_LIB 中发现的那样，如果那些符号 link 不是在那里，link 将失败。
configure checks whether the binary can run in the system, and not whether a program which uses these libraries can be build.
configure也有runtime测试以及编译和link时间测试，所以如果编译输出可以运行，它可以进行一些有限的测试。 configure 的主要作用是确保先决条件 installed/configured 所以 make 会起作用，所以测试工具、头文件、库是否已安装并以某种方式工作是 configure 大多数情况下。 运行时间测试在某些环境（交叉编译）中将不起作用，因此许多包不使用它们。
If I am not wrong, ./configure cannot be used for checking whether a binary can run in a system, as it is used in the case of building a program only.
configure 可以对 configure 已经构建的事物进行一些 运行 时间测试，如上面 link 中所述（例如 AC_RUN_IFELSE）。
If ./configure succeeds, then the binary can run in the machine.
But reverse is not true. That is , evenif ./configure fails, the binary may run, as it does not depened on development symlink(eg: libcurl.so).Am I right ?
您指的是哪个二进制文件？作为 AC_RUN_IFELSE 的一部分或 make 的输出创建的测试？如果 configure 成功，make 的输出可能仍然无效。这就是 make check 的用途。如果 configure 失败，很可能 make 将无法工作，并且您将无法到达可以测试 make.
输出的部分
如果场景缺少 libcurl.so，并且 configure 未能通过 link AC_TRY_LINK 测试，那么相同的 link 步骤如何运作然后为您的可执行文件，因为它也将取决于 libcurl.so 的 link 步骤？它确实取决于该文件（仅针对 link 步骤），因为您可能安装了多个 libcurl.so.x 库。
By binary...I mean the program that has been successfully build in some other system having all the dependencies installed.What I was telling is that the binary will run in a machine even if the development symlink(libcurl.so) is not there.
当然，它已经过了 link 步骤，并且 link 会说 libcurl.so.x 以及它可能具有的任何其他依赖项。
我正在制作一个 configure.ac 文件来检查库依赖性。
完整的代码是，
AC_CONFIG_AUX_DIR([build-aux])
AC_INIT([myprogram], [0.1], [])
AM_INIT_AUTOMAKE
AC_PROG_CC
AC_CHECK_LIB([curl], [curl_easy_setopt], [echo "libcurl library is present" > /dev/tty], [echo "libcurl library is not present" > /dev/tty] )
AC_CHECK_LIB([sqlite3], [sqlite3_open], [echo "sqlite3 library is present" > /dev/tty], [echo "sqlite library is not present" > /dev/tty] )
AC_CHECK_LIB([pthread], [pthread_create], [echo "pthread library is present" > /dev/tty], [echo "pthread library is not present" > /dev/tty] )
AC_CHECK_LIB([crypto], [SHA256], [echo "crypto library is present" > /dev/tty], [echo "crypto library is not present" > /dev/tty] )
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
"myprogram"是一个需要安装在众多用户pcs.So中的程序，开始时需要做依赖检查，看是否是这四个库已安装。
在 /usr/lib/i386-linux-gnu/libcurl.so 所在的系统中，当我 运行 配置文件时，它给出消息 "libcurl library is present"。但是，在存在 /usr/lib/i386-linux-gnu/libcurl.so.1.0 或类似内容的系统中，这表明 libcurl 不存在。如果我创建一个软 link 到 libcurl.so ，那么它正确地告诉 libcurl 存在。 ln -s /usr/lib/i386-linux-gnu/libcurl.so.1.0.0 /usr/lib/i386-linux-gnu/libcurl.so.Same 也适用于其他库。
实际上，我想使这个过程自动化。有没有办法做到这一点，而无需手动制作软 link？我的意思是，通过对 configure.ac 文件本身进行更改，这样配置将 运行 在没有需要制作软 link.
在安装库时，安装程序通常会创建一个符号 link 从库的真实名称 (libcurl.so.1.0.0) 到它的 linker 名称 (libcurl.so) 允许 linker 找到实际的库 file.But 它并不总是 true.Sometimes 它不会创建 linker name.That 是为什么这些并发症是 happening.So 检查 linker 名称的程序认为没有安装库。
In systems where, /usr/lib/i386-linux-gnu/libcurl.so is there, it is giving the message "libcurl library is present", when I run the configure file. But, in the systems where /usr/lib/i386-linux-gnu/libcurl.so.1.0 or something similar is present, it is telling that libcurl is not present.
是的，这是我所期望的行为。这里发生的事情是，AC_CHECK_LIB 发出一个带有你给它的符号的程序，然后 link（在本例中为 curl_easy_setopt），执行编译步骤和 link确保 link 人可以 link 的步骤。在典型的 Linux 发行版上，您需要确保安装了一些名为 libcurl-dev（或类似的东西）的软件包，因此您将拥有头文件和 libcurl.so sym link 已安装。
But I want to automate this process. Is there a way to do this, without manually making a soft link?
libcurl-dev 包的安装可以轻松实现自动化。它可以通过多种方式完成，具体取决于您想要的方式。 Linux 打包系统（例如 rpmbuild、debhelper 等）如果未安装，可以在构建之前引入构建依赖项。您用来设置构建机器的配置管理工具（例如 ansible、SaltStack 等）可以安装它。依赖项应至少列在发布文档中，以便如果无法访问这些工具（或不关心使用它们）的人可以弄清楚并构建。
我不会在 configure.ac 中创建 symlink -- 它可能会破坏 libcurl-dev 的任何未来安装。此外，您将 拥有 到 运行 configure 的提升权限（例如 sudo）来创建 link.
While installing a library, the installer program will typically create a symbolic link from the library's real name(libcurl.so.1.0.0) to its linker name(libcurl.so) to allow the linker to find the actual library file.But it is not always true.
实际上，我不记得见过这样的事情。通常，当 DSO 安装到 ldconfig "trusted directories"（例如 /usr/lib 等）时，ldconfig 会得到 运行，因此真正的库（例如 libcurl.so.1.0. 0) 在同一目录下得到一个symlink (libcurl.so.1)，但不是开发symlink (libcurl.so).
编辑：添加对评论的回复
But why ./configure also expects development symlink s(libcurl.so, libcrypto.so etc)
因为 configure 可以告诉 运行 那个 link 人，正如你在 AC_CHECK_LIB 中发现的那样，如果那些符号 link 不是在那里，link 将失败。
configure checks whether the binary can run in the system, and not whether a program which uses these libraries can be build.
configure也有runtime测试以及编译和link时间测试，所以如果编译输出可以运行，它可以进行一些有限的测试。 configure 的主要作用是确保先决条件 installed/configured 所以 make 会起作用，所以测试工具、头文件、库是否已安装并以某种方式工作是 configure 大多数情况下。 运行时间测试在某些环境（交叉编译）中将不起作用，因此许多包不使用它们。
If I am not wrong, ./configure cannot be used for checking whether a binary can run in a system, as it is used in the case of building a program only.
configure 可以对 configure 已经构建的事物进行一些 运行 时间测试，如上面 link 中所述（例如 AC_RUN_IFELSE）。
If ./configure succeeds, then the binary can run in the machine. But reverse is not true. That is , evenif ./configure fails, the binary may run, as it does not depened on development symlink(eg: libcurl.so).Am I right ?
您指的是哪个二进制文件？作为 AC_RUN_IFELSE 的一部分或 make 的输出创建的测试？如果 configure 成功，make 的输出可能仍然无效。这就是 make check 的用途。如果 configure 失败，很可能 make 将无法工作，并且您将无法到达可以测试 make.
如果场景缺少 libcurl.so，并且 configure 未能通过 link AC_TRY_LINK 测试，那么相同的 link 步骤如何运作然后为您的可执行文件，因为它也将取决于 libcurl.so 的 link 步骤？它确实取决于该文件（仅针对 link 步骤），因为您可能安装了多个 libcurl.so.x 库。
By binary...I mean the program that has been successfully build in some other system having all the dependencies installed.What I was telling is that the binary will run in a machine even if the development symlink(libcurl.so) is not there.
当然，它已经过了 link 步骤，并且 link 会说 libcurl.so.x 以及它可能具有的任何其他依赖项。