Autoconf Check for Program and Fail If Not Found

Autoconf check for program and fail if not found

Try this which is what I just lifted from a project of mine, it looks for something called quantlib-config in the path:

# borrowed from a check for gnome in GNU gretl: def. a check for quantlib-config
AC_DEFUN(AC_PROG_QUANTLIB, [AC_CHECK_PROG(QUANTLIB,quantlib-config,yes)])
AC_PROG_QUANTLIB
if test x"${QUANTLIB}" == x"yes" ; then
    # use quantlib-config for QL settings
    [.... more stuff omitted here ...]
else
    AC_MSG_ERROR([Please install QuantLib before trying to build RQuantLib.])
fi

autoconf check for missing prototype

Saving/restoring CFLAGS is acceptable but for this particular purpose, AC_CHECK_DECLS turns out to be precisely what I was looking for, and furthermore does not have any problems with super-picky compilers or trying to figure out what is the Portland Group compiler equivalent to -Werror-implicit-function-declaration.

AC_INIT([pwrite],[0.0.0],[none],[nothing],[nowhere])
AC_CONFIG_HEADERS([config.h])
AC_CHECK_HEADERS([unistd.h])
AC_CHECK_DECLS([pwrite])
AC_OUTPUT()

and then in my code I do have to check the result a little differently:

#if (HAVE_DECL_PWRITE == 0)
... implement our own pwrite 
#endif

Autoconf: Check if a program in an unsupported language compiles

AC_TRY_COMPILE (which is deprecated and replaced by AC_COMPILE_IFELSE) only supports a limited set of languages: C, C++, Fortran 77, Fortran, Erlang, Objective C, Objective C++ (source).

configure.ac can contain custom shell code - it just gets skipped over by autoconf (really m4). Why not just write your test in shell? If you're going to use more than one test, wrap it in an AC_DEFUN.

how to check the version of a program from inside autoconf script configure.ac

Sure. The general idea is to turn it into expressions a shell script can evaluate / something you can run from `configure. Below are three different approaches.

The first is some basic tests for g++ we had in the RQuantLib configure.ac package for many years (yes, that many years that we tested for g++-3.* ...). The main gist here is a wild card comparison.

AC_PROG_CXX
if test "${GXX}" = yes; then
    gxx_version=`${CXX} -v 2>&1 | grep "^.*g.. version" | \\
               sed -e 's/^.*g.. version *//'`
    case ${gxx_version} in
        1.*|2.*)
         AC_MSG_WARN([Only g++ version 3.0 or greater can be used with RQuantib.])
         AC_MSG_ERROR([Please use a different compiler.])
        ;;
    4.6.*|4.7.*|4.8.*|4.9.*|5.*|6.*|7.*|8.*|9.*|10.*)
         gxx_newer_than_45="-fpermissive"
    ;;
    esac
fi

Here is another version from RProtoBuf where we compile something to have the version bubble up as a true/false expression:

## also check for minimum version
AC_MSG_CHECKING([if ProtoBuf version >= 2.2.0])
AC_RUN_IFELSE([AC_LANG_SOURCE([[
#include <google/protobuf/stubs/common.h>
int main() {
   if (GOOGLE_PROTOBUF_VERSION >= 2001000) {
        exit (0);
   } else {
        exit(1);
   }
}
]])],
[pb_version_ok=yes],
[pb_version_ok=no],
[pb_version_ok=yes])
if test x"${pb_version_ok}" == x"no"; then
    AC_MSG_ERROR([Need ProtoBuf version >= 2.2.0])
else
    AC_MSG_RESULT([yes])
fi

And I think I did something more recently where I made it an package_version object in R so that one can compare---here it is from RcppRedis -- this again comes back to configure as a true/false.

## look for (optional !!) MsgPack headers
## RcppMsgPack on CRAN fits the bill -- but is a soft dependency
AC_MSG_CHECKING([for RcppMsgPack])
## Check if R has RcppMsgPack
$("${R_HOME}/bin/Rscript" --vanilla -e 'hasPkg <- "RcppMsgPack" %in% rownames(installed.packages()); q(save="no", status=if (hasPkg) packageVersion("RcppMsgPack") >= "0.2.0" else FALSE)')
if test x"$?" == x"1"; then
    AC_MSG_RESULT([yes])
    msgpackincdir=$("${R_HOME}/bin/Rscript" --vanilla -e 'cat(system.file("include", package="RcppMsgPack"))')
    msgpack_cxxflags="-I${msgpackincdir} -DHAVE_MSGPACK"
    AC_MSG_NOTICE([Found RcppMsgPack, using '${msgpack_cxxflags}'])
else
    AC_MSG_RESULT([no])
    AC_MSG_NOTICE([Install (optional) RcppMsgPack (>= 0.2.0) from CRAN via 'install.packages("RcppMsgPack")'])
fi  

I hope this gives you some ideas.

Autoconf : How to get program output in a string and check if another string is present in that

When writing a configure.ac for Autoconf, always remember that you are basically writing a shell script. Autoconf provides a host of macros that afford you a lot of leverage, but you can usually at least get an idea about basic "How can I do X in Autoconf?" questions by asking instead "How would I do X in a portable shell script?"

In particular, for ...

I would like to avoid the need of an extra variable for the program
output, but instead do it like this (Pseudo code):

if "pyrcc5" not in output of "pyrcc -version":
    say "pyrcc has wrong version"
    exit 1

... the usual tool for a portable shell script to use for such a task is grep, and, happily, the easiest way to apply it to the task does not require an intermediate variable. For example, this implements exactly your pseudocode (without emitting any extraneous messaging to the console):

if ! pyrcc -version | grep pyrcc5 >/dev/null 2>/dev/null; then
  echo "pyrcc has wrong version"
  exit 1
fi

That pipes the output of pyrcc -version into grep, and relies on the fact that grep exits with a success status if and only if it finds any matches.

You could, in fact, put exactly that in your configure.ac, but it would be more idiomatic to

• Use the usual Autoconf mechanisms to locate pyrcc and grep, and to use the versions discovered that way;
• Use the Autoconf AS_IF macro to write the if construct, instead of writing it literally;
• Use standard Autoconf mechanisms for emitting a "checking..." message and reporting on its result; and
• Use the standard Autoconf mechanism for outputting a failure message and terminating.

Of course, all of that makes the above considerably more complex, but also more flexible and portable. It might look like this:

AC_ARG_VAR([PYRCC], [The name or full path of pyrcc. Version 5 is required.])

# ...

AC_PROG_GREP
AC_CHECK_PROGS([PYRCC], [pyrcc5 pyrcc], [])
AS_IF([test "x${PYRCC}" = x],
  [AC_MSG_ERROR([Required program pyrcc was not found])])

# ...

AC_MSG_CHECKING([whether ${PYRCC} has an appropriate version])
AS_IF([! pyrcc -version | grep pyrcc5 >/dev/null 2>/dev/null], [
  AC_MSG_RESULT([no])
  AC_MSG_ERROR([pyrcc version 5 is required, but ${PYRCC} is a different version])
], [
  AC_MSG_RESULT([yes])
])

In addition to portability and conventional Autoconf progress messaging, that also gets the builder a way to specify a particular pyrcc executable to configure (by setting variable PYRCC in its environment), documents that in configure's help text, and exports PYRCC as a make variable.

Oh, and I snuck in a check for pyrcc under the name pyrcc5, too, though I don't know whether that's useful in practice.

The final result no longer looks much like the shell script fragment I offered first, I grant. But again, the pure shell script fragment could be used as is, and also, the fully Autoconfiscated version is derived directly from the pure script.

autotools, how to fail if cross compiler cannot be found

When you specify --host=<host-type>, and this value differs from the result of running the config.guess script, autoconf enters cross-compilation mode. Specifically, the variable cross_compiling is set to yes.

If the configure script is in 'cross-compilation' mode, it can't run any resulting executable, so there's no way to tell if a resulting binary is a valid 'host' binary or not. Presumably, a large database of file magic values might be able to tell if a valid host binary has been generated. Despite a couple of decades worth of experience built into the autotools, there are some combinatorial problems that can never keep up with all possible architectures and ABIs.

The autoconf C compiler tests check to see if the compiler - that is $CC - can build an executable. autoconf may provide a warning if the compiler is not prefixed with the host triplet, e.g., arm-none-eabi-gcc, but will not 'fail' if it finds a working compiler, such as the native gcc.

So, the only way to ensure cross-compilation with the correct compiler is to specify the compiler:

./configure --host=arm-none-eabi CC="arm-none-eabi-gcc"

If this compiler can't build executables, the configure script will fail.

autoconf: command not found

First, some general advice how you can solve this issue yourself, without having to come to [so] and waiting for someone else to solve your problem:

Computers are very good at searching. So, in 90% of cases, when a computer tells you that it couldn't find something, it is because that thing isn't there.

So, the first thing I would check, if I were in your situation, is whether the thing the computer tells me it can't find is actually there. In particular, I would check whether I have autoconf installed.

In the other 10% of cases, the thing the computer is looking for is there, but it is not somewhere the computer is looking. So, the second thing I would check is whether autoconf is in the $PATH.

Pretty much always, following those two steps solves the problem for me.

Now, on to your particular problem: when you want to compile some piece of software, you need the corresponding tools. Those tools include, but are not limited to, a compiler for the language the software is written in (in this case C), a build tool (in this case Make), the header files for all the libraries the software uses (in this case for example libyaml, zlib, OpenSSL), maybe some configuration tools (in this case autoconf). YARV also uses Bison to generate its parser.

Often, those required tools are listed in the developer or contributor documentation of the software. Although sometimes, it is just assumed that people who install software by compiling directly from source are clever enough to figure out which tools they need on their own. For YARV, there is documentation about the requirements for running the testsuite, which implicitly also requires building the code in the first place.

Debian-based Linux Distributions (Debian, Ubuntu, Mint, etc.) have a handy meta-package called build-essential that depends on some of the most important tools, e.g. gcc and make as well as the dpkg-dev metapackage (which in turn depend on lots of other packages).

The ASDF Ruby plugin actually uses ruby-build under the hood, and the documentation directly links to the system requirements, which list the following:

apt install autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm6 libgdbm-dev libdb-dev

---

Related Topics