Autoconf check for program and fail if not found - linux

I'm creating a project and using GNU Autoconf tools to do the configuring and making. I've set up all my library checking and header file checking but can't seem to figure out how to check if an executable exists on the system and fail if it doesn't exist.
I've tried:
AC_CHECK_PROG(TEST,testprogram,testprogram,AC_MSG_ERROR(Cannot find testprogram.))
When I configure it runs and outputs:
Checking for testprogram... find: `testprogram. 15426 5 ': No such file or directory
but does not fail.

I found this to be the shortest approach.
AC_CHECK_PROG(FFMPEG_CHECK,ffmpeg,yes)
AS_IF([test x"$FFMPEG_CHECK" != x"yes"], [AC_MSG_ERROR([Please install ffmpeg before configuring.])])

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

Similar to the above, but has the advantage of also being able to interact with automake by exporting the condition variable
AC_CHECK_PROG([ffmpeg],[ffmpeg],[yes],[no])
AM_CONDITIONAL([FOUND_FFMPEG], [test "x$ffmpeg" = xyes])
AM_COND_IF([FOUND_FFMPEG],,[AC_MSG_ERROR([required program 'ffmpeg' not found.])])

When using AC_CHECK_PROG, this is the most concise version that I've run across is:
AC_CHECK_PROG(BOGUS,[bogus],[bogus],[no])
test "$BOGUS" == "no" && AC_MSG_ERROR([Required program 'bogus' not found.])
When the program is missing, this output will be generated:
./configure
...cut...
checking for bogus... no
configure: error: Required program 'bogus' not found.
Or when coupled with the built-in autoconf program checks, use this instead:
AC_PROG_YACC
AC_PROG_LEX
test "$YACC" == ":" && AC_MSG_ERROR([Required program 'bison' not found.])
test "$LEX" == ":" && AC_MSG_ERROR([Required program 'flex' not found.])

Stumbled here while looking for this issue, I should note that if you want to have your program just looked in pathm a runtime test is enough:
if ! which programname >/dev/null ; then
AC_MSG_ERROR([Missing programname]
fi

This is not exactly a short approach, it's rather a general purporse approach (although when there are dozens of programs to check it might be also the shortest approach). It's taken from a project of mine (the prefix NA_ stands for “Not Autotools”).
A general purpose macro
dnl ***************************************************************************
dnl NA_REQ_PROGS(prog1, [descr1][, prog2, [descr2][, etc., [...]]])
dnl
dnl Checks whether one or more programs have been provided by the user or can
dnl be retrieved automatically. For each program `progx` an uppercase variable
dnl named `PROGX` containing the path where `progx` is located will be created.
dnl If a program is not reachable and the user has not provided any path for it
dnl an error will be generated. The program names given to this function will
dnl be advertised among the `influential environment variables` visible when
dnl launching `./configure --help`.
dnl ***************************************************************************
AC_DEFUN([NA_REQ_PROGS], [
m4_if([$#], [0], [], [
AC_ARG_VAR(m4_translit([$1], [a-z], [A-Z]), [$2])
AS_IF([test "x#S|#{]m4_translit([$1], [a-z], [A-Z])[}" = x], [
AC_PATH_PROG(m4_translit([$1], [a-z], [A-Z]), [$1])
AS_IF([test "x#S|#{]m4_translit([$1], [a-z], [A-Z])[}" = x], [
AC_MSG_ERROR([$1 utility not found])
])
])
m4_if(m4_eval([$# + 1 >> 1]), [1], [], [NA_REQ_PROGS(m4_shift2($*))])
])
])
Sample usage
NA_REQ_PROGS(
[find], [Unix find utility],
[xargs], [Unix xargs utility],
[customprogram], [Some custom program],
[etcetera], [Et cetera]
)
So that within Makefile.am you can do
$(XARGS)
or
$(CUSTOMPROGRAM)
and so on.
Features
It advertises the programs among the “influential environment variables” visible when the final user launches ./configure --help, so that an alternative path to the program can be provided
A bash variable named with the same name of the program, but upper case, containing the path where the program is located, is created
En error is thrown if any of the programs given have not been found and the user has not provided any alternative path for them
The macro can take infinite (couples of) arguments
When you should use it
When the programs to be tested are vital for compiling your project, so that the user must be able to provide an alternative path for them and an error must be thrown if at least one program is not available at all
When condition #1 applies to more than one single program, in which case there is no need to write a general purpose macro and you should just use your own customized code

Related

How can I add an argument for executable linux file

I have a executable linux file called "Fyserver". I want to open it with this arg
./Fyserver --pass 2849
If I don't enter this --pass arg to ELF, then it should exit itself without even running. Is there a way to do this?
NOTE: I don't have the source code of this ELF. I want to do it in bash.
There is no sane way to do what you are asking. You can't add new behavior to a binary without access to the source code or some serious reverse engineering skills.
The usual solution is to create a simple wrapper, i.e. move ./Fyserver to ./Fyserver.real and create a script like
#!/bin/sh
[ "$1" = "--pass" ] || { echo "Syntax: $0 --pass <pass>" >&2; exit 127; }
exec ./Fyserver.real "$#"
The argument checking could arguably be more sophisticated, but this should at least give you an idea of how this is usually handled.
If you really wanted to, I suppose you could write this logic in a compiled language, and embed the original binary within it somehow.

SConstruct 101—moving on from Makefiles

Like
make,
scons has a large number of predefined variables and rules. (Try scons | wc on an SConstruct containing env = Environment(); print(env.Dump()) to see how extended the set is.)
But suppose we aren't after the wizardry of presets but rather want to do something a lot more primitive—simulating launching a few instructions from the (bash, etc) command line?
Also suppose we're quite happy with the default Decider('MD5'). What is the translation of the one-souce-one-target:
out/turquoise.xyz: out/chartreuse.xyz
chartreuse_to_turquoise $< $#
of the two-source-one-target:
out/purple.xyz: out/lilac.xyz out/salmon.xyz
gen_purple $< $#
and of:
run_this:
python prog.py
which we would run on-demand by typing make run_this?
What does the SConstruct for these elementary constructs look like?
All the answers you're looking for are in the users guide (and manpage)
Firstly, assuming you don't want to scan the input files to add included files specified in the input files, you can use Commmand()
(See info here: https://scons.org/doc/production/HTML/scons-user.html#chap-builders-commands)
Then you'll want an alias to specify an a non file command line target
(See here:https://scons.org/doc/production/HTML/scons-user.html#chap-alias)
Putting those two together yields
env=Environment()
# one source, one target
env.Command('out/turquoise.xyz', 'out/chartreuse.xyz', 'chartreuse_to_turquoise $SOURCE $TARGET')
# Two source, one target
env.Command('out/purple.xyz',['out/lilac.xyz','out/salmon.xyz'], 'gen_purple $SOURCES $TARGET')
# And your .phony make target which is actually not great for reproducibility and determining when it should be rerun, because you do not specify any sources or targets
env.Alias('run_this','python prog.py')
Note: SCons doesn't NOT propagate your shell environment variables. So if you depend on (for example) a non system path in your PATH, you'll need to explicitly specify that in env['ENV']['PATH'] for example. For more details take a read through the users guide, manpage and FAQ.
https://scons.org/doc/production/HTML/scons-user.html
https://scons.org/doc/production/HTML/scons-man.html
https://scons.org/faq.html
And you can reach the community directly via our discord server, IRC channel, or users mailing list

Ambiguous redirect when running configure with hush

I am running a simple linux system with busybox and hush as the shell.
When I try to run the standard "./configure" for compiling programs, I always get the following error:
/Programs/blazeos/build/bison-3.4.1 # ./configure
hush: ambiguous redirect
hush: syntax error at 'fi'
If I run it with "ash ./configure" it runs without any problems, so it seems to be related to the hush shell. Does anyone know why this is happening or how I can debug it? I have tried it with several different source packages, such as "flex", "bison", "m4" etc. and I always get the same error.
This happens in as_fn_error:
as_fn_error ()
{
as_status=$1; test $as_status -eq 0 && as_status=1
if test "$4"; then
as_lineno=${as_lineno-"$3"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
$as_echo "$as_me:${as_lineno-$LINENO}: error: $2" >&$4
fi
$as_echo "$as_me: error: $2" >&2
as_fn_exit $as_status
} # as_fn_error
This happens because >&$4 (getting the file descriptor number to redirect to by evaluating $4) is not supported in hush. Arguably, this violates the letter of the POSIX sh standard; bolding for emphasis is mine:
The redirection operator: [n]>&word shall duplicate one output file descriptor from another, or shall close one. If word evaluates to one or more digits, the file descriptor denoted by n, or standard output if n is not specified, shall be made to be a copy of the file descriptor denoted by word
As I read the specification, "evaluates to" means that expansions should be run, so using a parameter expansion should be legal in that location. Thus, this is (arguably) a missing feature in hush that would be required for standards compliance.
If you're interested in trying to work around the issue, in all the cases where this optional parameter is used, it's given a hardcoded value of 5. Thus, you could simply change >&$4 to >&5, and this specific error would be avoided.

What does it mean to invoke `make -f` with a target that appears to be setting a variable? (And why isn't it working for me?)

Summary
I am trying to understand a complicated chain of Makefiles, in order to get a build to succeed. I narrowed down my problem to this bit in our build script:
INF_RL=`make -f $BUILD_ROOT/Makefile BUILD_ROOT_MAKEFILE= show__BUILD_INF_RL`
$INF_RL/$BUILD_UTILS_RELDIR/BuildAll.sh
$INF_RL is being set to an empty string (or not being set). If I replace the first line with
INF_RL=/foo_rel_linx86/infrastructure_release/v8.0.14
in order to hardcode what I know $INF_RL is supposed to be, then the build goes smoothly. But I want to know how to fix this the proper way.
What I've Tried / Thought
My first thought was that make -f is failing. So I tried it in my shell:
% make -f $BUILD_ROOT/Makefile BUILD_ROOT_MAKEFILE= show__BUILD_INF_RL
% setenv | grep BUILD_ROOT
BUILD_ROOT=/userhome/andrew.cheong/TPS
Indeed, it returned an empty string. But what conclusion could I draw from this? I wasn't sure if the shell was the same thing as the environment / scope in which Make was chaining together its Makefiles. I abandoned this investigation.
Next, I looked into show__BUILD_INF_RL, which seemed to be defined in $BUILD_ROOT/Makefile:
BUILD_ROOT_MAKEFILE = 1
MAKE_DIRS = src
CASE_KITS = tpsIn tpsOut
REQUIRED_VERSIONS = "case.v$(INF_VS)"
all:
## These next 3 rules allows any variable set in this makefile (and therefore
## the included makefile.include to have it's value echoed from the command
## "make show_<variableName>"
## NOTE: the "disp" target is vital as it allows the show_% implicit rule to be
## recognised as such - implicit rules *must* have a target.
show_% := DISPLAY_MACRO = $(#:show_%=%)
show_% : disp
# echo $($(DISPLAY_MACRO))
disp:
include $(BUILD_ROOT)/makefile.include
Here, I faced more questions:
What is BUILD_ROOT_MAKEFILE for? Why is it set to 1, then seemingly something else in the make -f command?
In the make -f command, is BUILD_ROOT_MAKEFILE= its own argument? If so, what kind of target or rule is that? Otherwise, why is it being set to the macro?
In $BUILD_ROOT, there is another file, makefile.LINUX_X86.include:
BUILD_INF_RL = /foo_rel_linx86/infrastructure_release/v$(INF_VS)
$(warning $(BUILD_INF_RL))
BUILD_UTILS = $(BUILD_INF_RL)/build-utils_LINUX_X86
Though a completely ignorant guess, I think BUILD_INF_RL is being set here, and intended to be extracted into the build script's variable INF_RL when the macro show__BUILD_INF_RL is invoked. I added the middle line to see if it was indeed being set, and indeed, I get this output when running the build script:
/userhome/andrew.cheong/TPS/makefile.LINUX_X86.include:3: /foo_rel_linx86/infrastructure_release/v8.0.14
i.e. Looks like what I've hardcoded way above! But why doesn't it make it into INF_RL? There is yet another file, makefile.include, also in $BUILD_ROOT:
#
# INCLUDE THIS FILE AS THE LAST LINE IN THE LOCAL MAKEFILE
#
# makefile.include - use this file to define global build settings
# e.g. infrastructure version and location, or third-party
#
# supported macros in addition to build-utils-makefile.include
#
# BUILD_INF_RL : optional, specification of infrastructure release location
# defaults to vdev_build area
#
include $(BUILD_ROOT)/../../makefile.include.$(BUILD_ARCH).Versions
#include $(BUILD_UTILS)/makefile.archdef.include
include $(BUILD_ROOT)/makefile.$(BUILD_ARCH).include
$(warning $(BUILD_INF_RL))
_BUILD_INF_RL = $(BUILD_INF_RL)
# place the results at the root of the infdemo tree
BUILD_DEST = $(BUILD_ROOT)
INCLUDE_DIRS += $(BUILD_INF_RL)/core/$(BUILD_TARGET)/include
LINK_DIRS += $(BUILD_INF_RL)/core/$(BUILD_TARGET)/lib
# libraries required for a typical fidessa app, including OA and DB access
FIDEVMAPP_LIBS = FidApp FidInf FidCore Fidevm
include $(BUILD_UTILS)/makefile.include
That $(warning ...) is again mine, and when running the build script, I get:
/userhome/andrew.cheong/TPS/makefile.include:18: /foo_rel_linx86/infrastructure_release/v8.0.14
The Question
The fact that both $(warning ...)s show up when I run the build script that's calling the make -f ... show__BUILD_INF_RL, tells me that those Makefiles are being included. Then what is causing the macro to fail and return an empty string instead of the correct INF_RL path?
Historical Notes
These build scripts were written at a time when we were only compiling for Solaris. (The scripts were based on templates written by an infrastructure team that loosely accounted for both Solaris and Linux, but we never ran the Linux branch, as it was unnecessary.) We are now fully migrating to Linux, and hitting this issue. The reason I'm skeptical of it being a Linux versus Solaris issue is that we have at least four other products that use a similar Makefile chain and have been migrated with no issues. Not sure why this one in particular is behaving different.
Your question got very long and complex so I didn't read it all... for SO it's often better if you just ask a specific targeted question that you want to know the answer to, with a simple repro case.
I can't say why different makefiles behave differently, but this line:
show_% := DISPLAY_MACRO = $(#:show_%=%)
seems really wrong to me. This is (a) setting the variable show_%, which don't actually use anywhere, (b) to the simply expanded string DISPLAY_MACRO = because at this point in the makefile the variable $# is not set to any value.
Maybe you wanted this line to be this instead:
show_% : DISPLAY_MACRO = $(#:show_%=%)
(note : not :=) so that it's a pattern-specific variable assignment, not a simple variable assignment?

g++ searches /lib/../lib/, then /lib/

According to g++ -print-search-dirs my C++ compiler is searching for libraries in many directories, including ...
/lib/../lib/:
/usr/lib/../lib/:
/lib/:
/usr/lib/
Naively, /lib/../lib/ would appear to be the same directory as /lib/ — lib's parent will have a child named lib, "that man's father's son is my father's son's son" and all that. The same holds for /usr/lib/../lib/ and /usr/lib/
Is there some reason, perhaps having to do with symbolic links, that g++ ought to be configured to search both /lib/../lib/ and /lib/?
If this is unnecessary redundancy, how would one go about fixing it?
If it matters, this was observed on an unmodified install of Ubuntu 9.04.
Edit: More information.
The results are from executing g++ -print-search-dirs with no other switches, from a bash shell.
Neither LIBRARY_PATH nor LPATH are output from printenv, and both echo $LPATH and echo LIBRARY_PATH return blank lines.
An attempt at an answer (which I gathered from a few minutes of looking at the gcc.c driver source and the Makefile environment).
These paths are constructed in runtime from:
GCC exec prefix (see GCC documentation on GCC_EXEC_PREFIX)
The $LIBRARY_PATH environment variable
The $LPATH environment variable (which is treated like $LIBRARY_PATH)
Any values passed to -B command-line switch
Standard executable prefixes (as specified during compilation time)
Tooldir prefix
The last one (tooldir prefix) is usually defined to be a relative path:
From gcc's Makefile.in
# Directory in which the compiler finds libraries etc.
libsubdir = $(libdir)/gcc/$(target_noncanonical)/$(version)
# Directory in which the compiler finds executables
libexecsubdir = $(libexecdir)/gcc/$(target_noncanonical)/$(version)
# Used to produce a relative $(gcc_tooldir) in gcc.o
unlibsubdir = ../../..
....
# These go as compilation flags, so they define the tooldir base prefix
# as ../../../../, and the one of the library search prefixes as ../../../
# These get PREFIX appended, and then machine for which gcc is built
# i.e i484-linux-gnu, to get something like:
# /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/lib/../lib/
DRIVER_DEFINES = \
-DSTANDARD_STARTFILE_PREFIX=\"$(unlibsubdir)/\" \
-DTOOLDIR_BASE_PREFIX=\"$(unlibsubdir)/../\" \
However, these are for compiler-version specific paths. Your examples are likely affected by the environment variables that I've listed above (LIBRARY_PATH, LPATH)
Well, theoretically, if /lib was a symlink to /drive2/foo, then /lib/../lib would point to /drive2/lib if I'm not mistaken. Theoretically...
Edit: I just tested and it's not the case - it comes back to /lib. Hrm :(

Resources