1

configure.ac can contains checks for headers and libraries:

AC_CHECK_LIB(cap,cap_compare,[cap_libs="-lcap"])
AC_CHECK_HEADERS([sys/acl.h linux/netlink.h])

As there an autotools support just to simply get list of these files (their default location even if not presented or at least location to these which are presented):

/usr/include/sys/acl.h
/lib/x86_64-linux-gnu/libcap.so.2

I'm trying to find/create tool which would from autotools input generated missing packages of a Linux distro.

UPDATE I see I didn't express myself correctly and mislead you with incorrect statements. I'm one of the developers of LTP project. I extended our autotools macros, so I have some knowledge how it works. As this project is aimed to be compiled from source code (there is not going to be a package in distros), I want to make it easy for users compiling it to provide it list of package dependencies for all major Linux distros.

It would probably be easiest way just to maintain these dependencies manually. But because we have these dependencies in form of autotools AC_CHECK_LIB() and AC_CHECK_HEADERS() macros, I'd like to use that. Somehow take input of autotools (configure.ac and all m4/*.m4) and generate list of headers and directories:

sys/acl.h
linux/netlink.h
...

libcap.so
...

This list would be big help for me. This is what I want to know.

Of course, I can make this list manually or use regular expressions to parse it either from autotools or from source code, but it would be nice to get it from autotools out of the box.

Ideas what to do with this list: I'd have another script with predefined include path and default library path (/usr/include/ would be include path for most distros add e.g. /lib/x86_64-linux-gnu/ for Debian/Ubuntu or /usr/lib64 for openSUSE) which I put in front of headers and libraries. IMHO pkg-config is not an option as it's *.pc config files are installed with dependencies, so it will not be available when the package I'm searching for isn't installed.

Then I'd search with this list for packages, using distribution tools which are able to search online (i.e. don't depend on package being installed, i.e. apt-file for Debian/Ubuntu, dnf, yum or zypper) or search online (https://packages.qa.debian.org/, ...), but that's another topic.

pevik
  • 4,523
  • 3
  • 33
  • 44
  • Hi, I'm having trouble understanding your question. Could you re-formulate it in some way, or add more details/examples? – Gunee Nov 29 '17 at 20:04
  • 1
    Regarding your update: my answer already addresses your revised question. To recap: substitute *the implementations* of Autoconf's standard `AC_CHECK_LIB`, `AC_CHECK_HEADER`, *etc*. macros with alternatives that emit the names of the checked-for items to a file instead of actually checking. Possibly dummy out some other macros. Generate the analog of a `configure` script from the original `configure.ac` and any added Autoconf sources, then run it. – John Bollinger Dec 01 '17 at 18:52

2 Answers2

1

As there an autotools support just to simply get list of these files (their default location even if not presented or at least location to these which are presented):

You seem to have a misunderstanding about how Autoconf works. It has no specific knowledge of where to locate headers or libraries, and certainly no concept of a default location. Rather, it uses the compiler and linker it previously discovered, and any flags that have been set in its standard variables, to check the presence of header files and libraries.

The compiler has a built-in search path for headers, and the linker similarly has a built-in search path for libraries. These may be augmented by -I, -L, and other flags that are in $CPPFLAGS, $CFLAGS, and $LDFLAGS, as appropriate, at the point where the checks are performed. The combination of these determines what locations are searched for any particular header or library, but again, not directly by the configure script itself.

I'm trying to find/create tool which would from autotools input generated missing packages of a Linux distro.

Well, you can certainly parse the Autoconf input file. In fact, inasmuch as it is designed to be processed via m4 anyway, you could write a replacement set of m4 macros and configuration that serve up the details of the AC_CHECK_HEADER, AC_CHECK_LIB, etc. macros that are invoked. You can that way get a pretty good idea of what libraries are required to build the package, but not of specific directories in which to find them.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
0

I will assume here that you are not the owner of the configure.ac files. Unfortunately for you, I don't think that such a tool exists.

According to William Pursell's answer in this post, autotools is not a package manager, so it knows nothing about packages as such, as a Linux distro's package manager would.

pkg-config brings some notion of packages to autotools, but according to the post I linked earlier, the results it gives could be wrong, especially if you think about cross-compilation.

However, you could still use the pkg-config macros inside the configure.ac to try and identify which packages (known by your OS' package manager) are missing.

Regarding the AC_CHECK_LIB and AC_CHECK_HEADERS, I believe you will have a hard time using them to generate absolute paths of the missing headers and libraries for the following reasons:

  • The prefix of the location of header and library files depends on the distribution (the historical /usr/lib vs the newer /usr/lib/x86_64-linux seen on Ubuntu 16.04 for ex)
  • The same thing is true inside a distribution itself (/usr/lib vs /usr/local/lib)
  • Some OS package managers will not give you a list of files contained in a given package, unless the package is actually already installed on your system (this is the case of apt on Ubuntu 16.04)
  • Packages containing a given library might not have the same name on distinct distros (I remember having this issue when using Fedora after Ubuntu, I couldn't find any of the packages I was used to)

In short, I don't think such a tool exists (but could be wrong), and writing one could reveal quite complicated, and heavily tied to one particular OS/distribution.

Gunee
  • 431
  • 3
  • 16