0

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

The complete code is,

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" 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.

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.

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.

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.

el.pescado - нет войне
  • 18,889
  • 4
  • 46
  • 89
BusyTraveller
  • 183
  • 3
  • 14
  • Maybe related... [How to tell Autoconf “require symbol A or B” from LIB?](https://stackoverflow.com/q/39285733/608639) – jww Jun 05 '17 at 13:10
  • This is stackoverflow. Show us the code. A configure check for a library should just try to link with it and if it works, it works... – Daniel Stenberg Jun 05 '17 at 13:45
  • You might want to check out the various way of [printing messages](https://www.gnu.org/software/autoconf/manual/autoconf.html#Printing-Messages) in autoconf, too. pthread has some special requirements, so there's a [macro](https://www.gnu.org/software/autoconf-archive/ax_pthread.html) for it. While you're at it you might want to check for the other libs you have at the [autoconf archive](https://www.gnu.org/software/autoconf-archive/The-Macros.html#The-Macros) where people on the net have written macros for all the libs you're looking for. – ldav1s Jun 07 '17 at 04:57

1 Answers1

2

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.

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?

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.

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.

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.

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).

EDIT: Adding responses to comments

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

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 checks whether the binary can run in the system, and not whether a program which uses these libraries can be build.

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.

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 can do some runtime testing of things configure has built as mentioned in the link above (e.g. 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 ?

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.

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.

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.

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

ldav1s
  • 15,885
  • 2
  • 53
  • 56
  • if I am developing some programs using these libraries, obviously it will be looking for the development symlinks(libcurl.so. libcrypto.so etc). But why ./configure also expects development symlink s(libcurl.so, libcrypto.so etc). configure checks whether the binary can run in the system, and not whether a program which uses these libraries can be build. Am I right? – BusyTraveller Jun 06 '17 at 05:23
  • Because `./configure` is used for developing programs using some libraries. – el.pescado - нет войне Jun 06 '17 at 05:29
  • so, you mean ./configure checks whether a program can be build using the libraries.Yes, that is correct.My mistake.Thanks.Can you kindly tell me the standard procedure to check whether a program using certain libraries can run in a system.I mean , the automated or programatic way of determining whether a library dependent program can run in a system. – BusyTraveller Jun 06 '17 at 05:34
  • 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.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 ? – BusyTraveller Jun 06 '17 at 05:53
  • 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. Because it can run with libcurl.so.1 or libcurl.so.2 and so on.But for building the program (libcurl.so) should be there. Otherwise ./configure will fail. – BusyTraveller Jun 07 '17 at 05:38