我正在制作一个检查库依赖性的 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"是一个需要安装在众多用户PC中的程序。因此，需要在开始时进行依赖关系检查，以查找是否安装了这四个库。
在/usr/lib/i386-linux-gnu/libcurl.so 所在的系统中，当我运行配置文件时，它会给出消息"libcurl 库存在"。但是，在存在/usr/lib/i386-linux-gnu/libcurl.so.1.0 或类似内容的系统中，libcurl 不存在。如果我创建一个指向 libcurl.so 的软链接，那么它正确地告诉 libcurl 存在。 ln -s/usr/lib/i386-linux-gnu/libcurl.so.1.0.0/usr/lib/i386-linux-gnu/libcurl.so.same也适用于其他库。
实际上，我想自动化此过程。有没有办法做到这一点，而无需手动创建软链接？我的意思是，通过在 configure.ac 文件本身进行更改，以便配置将在任何机器上运行，而无需进行软链接。
安装库时，安装程序通常会创建一个从库的真实名称 (libcurl.so.1.0.0) 到其链接器名称 (libcurl.so) 的符号链接，以允许链接器查找实际的库文件。但这并不总是正确的。有时它不会创建链接器名称。这就是为什么这些并发症正在发生。因此，检查链接器名称的程序认为未安装该库。
在/usr/lib/i386-linux-gnu/libcurl.so 存在的系统中，当我运行配置文件时，它会给出消息"libcurl 库存在"。但是，在存在/usr/lib/i386-linux-gnu/libcurl.so.1.0 或类似内容的系统中，libcurl 不存在。
是的，这就是我所期望的行为。 这里发生的事情是，AC_CHECK_LIB发出一个程序，其中包含您给它的符号以尝试链接(在本例中为curl_easy_setopt)，执行编译步骤和链接步骤以确保链接器可以链接。 在典型的 Linux 发行版上，您需要确保安装了名为libcurl-dev(或类似的东西)的软件包，以便安装头文件和libcurl.so符号链接。
但我想自动化这个过程。有没有办法做到这一点，而无需手动制作软链接？
libcurl-dev包的安装可以轻松实现自动化。可以通过多种方式完成它，具体取决于您想要如何完成。Linux 打包系统(例如 rpmbuild、debhelper 等)有办法在构建之前拉入构建依赖项，如果它们没有安装。 用于设置构建计算机的配置管理工具(例如ansible，SaltStack等)可以安装它。 依赖项至少应列在发布文档中，以便如果无法访问这些工具(或不关心使用它们)的人可以弄清楚并构建它。
我不会在configure.ac中创建符号链接 - 它可能会破坏任何未来的libcurl-dev安装。 此外，您必须使用提升的权限(例如 sudo)运行configure才能创建链接。
安装库时，安装程序通常会创建一个从库的真实名称 (libcurl.so.1.0.0) 到其链接器名称 (libcurl.so) 的符号链接，以允许链接器查找实际的库文件。但这并不总是正确的。
实际上，我不记得见过这样的东西。 通常，当 DSO 安装到 ldconfig "受信任目录"时(例如/usr/lib等)ldconfig运行，因此真正的库(例如libcurl.so.1.0.0)在同一目录中获取符号链接(libcurl.so.1)，而不是开发符号链接(libcurl.so)。
编辑：添加对评论的回复
但是为什么 ./configure 也期望开发符号链接 s(libcurl.so、libcrypto.so 等)
因为可以告诉configure运行链接器，正如您在AC_CHECK_LIB中发现的那样，如果这些符号链接不存在，链接将失败。
配置检查二进制文件是否可以在系统中运行，而不是检查是否可以构建使用这些库的程序。
configure还具有运行时测试以及编译和链接时测试，因此如果编译的输出可以运行，则可以进行一些有限的测试。configure的主要作用是确保安装/配置先决条件，以便make工作，因此测试工具，标头，库是否已安装并以某种方式工作是configure主要做的事情。 运行时测试在某些环境(交叉编译)中不起作用，因此许多包不使用它们。
如果我没记错的话，./configure 不能用于检查二进制文件是否可以在系统中运行，因为它仅用于构建程序的情况。
configure可以对configure构建的东西进行一些运行时测试，如上面的链接(例如AC_RUN_IFELSE)。
如果 ./configure 成功，则二进制文件可以在计算机中运行。 但反之则不然。也就是说，即使 ./configure 失败，二进制文件也可以运行，因为它不会在开发符号链接(例如：libcurl.so)上降级。我说的对吗？
你指的是哪个二进制文件？ 作为AC_RUN_IFELSE的一部分创建的测试还是make的输出？ 如果configure成功，make的输出可能仍然不起作用。 这就是make check的目的。 如果configure失败，很可能make不起作用，并且您将无法到达可以测试make输出的部分。
如果方案缺少 libcurl.so，并且configure无法链接AC_TRY_LINK测试，那么相同的链接步骤将如何适用于可执行文件，因为它也取决于链接步骤的 libcurl.so？ 它确实取决于该文件(仅用于链接步骤)，因为您可能安装了多个libcurl.so.x库。
按二进制...我的意思是已在安装了所有依赖项的其他系统中成功构建的程序。我说的是，即使开发符号链接(libcurl.so)不存在，二进制文件也会在机器中运行。
当然，它已经通过了链接步骤，并链接到libcurl.so.x以及它可能具有的任何其他依赖项。