使OS独立的配置文件检查curl依赖关系 [英] Making os independent configure file which checks for curl dependency

问题描述

我正在制作一个configure.ac文件，用于检查库依赖性.

I am making a configure.ac file which checks for library dependency.

完整的代码是

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中安装的程序.因此，一开始就需要进行依赖性检查，以查找是否已安装了这四个库.

"myprogram" is a program which needs to be installed in numerous user pcs.So, dependency check needs to be done in the begining, to find whether those four libraries are installed.

在运行/usr/lib/i386-linux-gnu/libcurl.so的系统中，运行配置文件时，它发出消息存在libcurl库".但是，在存在/usr/lib/i386-linux-gnu/libcurl.so.1.0或类似文件的系统中，这表明libcurl不存在.如果我创建到libcurl.so的软链接，那么它正确地告诉您存在libcurl. 在-s/usr/lib/i386-linux-gnu/libcurl.so.1.0.0/usr/lib/i386-linux-gnu/libcurl.so中.同样适用于其他库.

In the 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. If I create a soft link to libcurl.so , then it is telling correctly that libcurl is present. ln -s /usr/lib/i386-linux-gnu/libcurl.so.1.0.0 /usr/lib/i386-linux-gnu/libcurl.so.Same holds good for other libraries as well.

实际上，我想使这一过程自动化.有没有一种方法，而无需手动进行软链接?.我的意思是，通过对configure.ac文件本身进行更改，以便configure可以在任何计算机上运行，​​而无需进行软链接.

Actually, I want to automate this process. Is there a way to do this, without manually making a soft link?.I mean, by making changes in the configure.ac file itself, so that configure will run in any machine without the need for making soft link.

在安装库时，安装程​​序通常会创建从库的真实名称(libcurl.so.1.0.0)到其链接器名称(libcurl.so)的符号链接，以允许链接器查找实际的库文件但这并不总是正确的，有时它不会创建链接器名称，这就是为什么会出现这些复杂性的原因，因此检查链接器名称的程序认为未安装该库.

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.Sometimes it will not create the linker name.That is why these complications are happening.So the program which checks for the linker name, thinks that the library is not installed.

推荐答案

在运行/usr/lib/i386-linux-gnu/libcurl.so的系统中，当我运行配置文件时，它给出消息存在libcurl库".但是，在存在/usr/lib/i386-linux-gnu/libcurl.so.1.0或类似文件的系统中，这表明libcurl不存在.

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会发出一个程序，其中包含您赋予它的符号以尝试进行链接(在本例中为curl_easy_setopt)，执行编译步骤和链接步骤以确保链接器可以链接.在典型的Linux发行版上，您需要确保安装了名为libcurl-dev(或类似名称)的软件包，因此，您将安装头文件和libcurl.so symlink.

Right, this is the behavior I would expect. What's going on here is that AC_CHECK_LIB emits a program with the symbol you gave it to try and link (in this case curl_easy_setopt), does a compilation step and a link step to make sure the linker can link. On a typical Linux distro you'll want to make sure that some package called libcurl-dev (or something like that) is installed, so you'll have the header files and the libcurl.so symlink installed.

但是我想使这个过程自动化.有没有一种方法，而无需手动进行软链接?

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等)进行安装.依赖关系应至少在发行文档中列出，以便如果无法访问这些工具(或不愿意使用它们)的人可以找出并进行构建.

Installation of the libcurl-dev package can be easily automated. It can be accomplished several ways, depending on how you want to do it. Linux packaging systems (e.g. rpmbuild, debhelper, etc.) have ways of pulling in build dependencies before building if they aren't installed. Configuration management tools that you use to set up the build machine (e.g. ansible, SaltStack, etc.) could install it. The dependency should be listed in the release documentation at a minimum, so that if someone who has no access to these tools (or doesn't care to use them) can figure it out and build.

我不会在configure.ac中创建符号链接-可能会破坏以后安装的libcurl-dev.此外，您将必须以提升的特权(例如sudo)运行configure来创建链接.

I wouldn't create a symlink in configure.ac -- it would likely break any future install of libcurl-dev. Furthermore you would have to run configure with elevated privileges (e.g. sudo) to create the link.

在安装库时，安装程​​序通常会创建从库的真实名称(libcurl.so.1.0.0)到其链接器名称(libcurl.so)的符号链接，以允许链接器查找实际的库文件.但并非总是如此.

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的受信任目录"(例如/usr/lib等)时，会运行ldconfig，因此真实库(例如libcurl.so.1.0.0)将获得符号链接(libcurl.so.1). )放在同一目录中，但不在开发符号链接(libcurl.so)中.

Actually, I don't ever remember seeing anything like this. Typically when a DSO gets installed to the ldconfig "trusted directories" (e.g. /usr/lib, etc.) ldconfig gets run so the real library (e.g. libcurl.so.1.0.0) gets a symlink (libcurl.so.1) in the same directory, but not the development symlink (libcurl.so).

添加评论回复

但是为什么./configure也期望开发符号链接s(libcurl.so，libcrypto.so等)

But why ./configure also expects development symlink s(libcurl.so, libcrypto.so etc)

因为您可以通过 AC_CHECK_LIB ，如果这些符号链接不存在，则链接将失败.

Because configure can be told to run the linker, as you discovered with AC_CHECK_LIB, and if those symlinks aren't there, the link will fail.

configure检查二进制文件是否可以在系统中运行，以及是否可以构建使用这些库的程序.

configure checks whether the binary can run in the system, and not whether a program which uses these libraries can be build.

configure还具有运行时测试作为编译和链接时间测试，因此如果可以运行编译输出，则可以进行一些有限的测试. configure的主要作用是确保先决条件的安装/配置，以便make可以正常工作，因此configure大多数情况下，测试工具，标头，库是否已安装并以某种方式工作.在某些环境(交叉编译)中，运行时测试将不起作用，因此许多程序包不使用它们.

configure also has runtime tests as well as compile and link time tests, so it can to some limited testing if the output of compilation can run. configure's primary role is to ensure that prerequisites are installed/configured so make will work, so testing that tools, headers, libraries are installed and work in some fashion is what configure mostly does. The runtime tests will not work in some environments (cross-compilation), so lots of packages don't use them.

如果我没记错，./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已构建的东西(例如AC_RUN_IFELSE)进行一些运行时测试.

configure can do some runtime testing of things configure has built as mentioned in the link above (e.g. AC_RUN_IFELSE).

如果./configure成功，则二进制文件可以在计算机中运行. 但是反向不是真的.也就是说，即使./configure失败，二进制文件也可能运行，因为它不依赖于开发符号链接(例如libcurl.so).我对吗?

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的输出.

Which binary are you referring to? The test created as part of AC_RUN_IFELSE or the output of make? If configure suceeeds, the output of make still might not work. That's what make check is for. If configure fails, it's likely make won't work, and you won't get to the part where you can test the output of make.

如果方案缺少libcurl.so，并且configure无法链接AC_TRY_LINK测试，那么该链接步骤如何对您的可执行文件起作用，因为该链接还将依赖于libcurl.so步?它确实取决于该文件(仅用于链接步骤)，因为您可能安装了多个libcurl.so.x库.

If the scenario is a missing libcurl.so, and configure fails to link the AC_TRY_LINK test, how's that same link step going to work for your executable then, because it's also going to depend on libcurl.so for the link step? It does depend on that file (just for the link step), because you may have multiple libcurl.so.x libraries installed.

通过二进制文件...我的意思是已经在安装了所有依赖项的其他系统中成功构建的程序.我说的是即使开发符号链接(libcurl.so)，二进制文件也可以在计算机上运行.不在那里.

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.

当然，它已经超出了链接步骤，并链接到libcurl.so.x以及它可能具有的任何其他依赖项.

Sure, it's already gone past the link step and is linked to say libcurl.so.x and whatever other dependencies it may have.

这篇关于使OS独立的配置文件检查curl依赖关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！