This is my whole configure.ac(generated by autoscan),and i add a line AC_PREIX_CONFIG_H(hotplugin) in this script:
AC_PREREQ([2.63])
AC_INIT([hotplugin], [0.1])
AC_CONFIG_SRCDIR([loader.c])
AC_CONFIG_HEADERS([config.h])
# Checks for programs.
AC_PROG_CXX
AC_PROG_CC
# Checks for libraries.
# FIXME: Replace `main' with a function in `-ldl':
AC_CHECK_LIB([dl], [main])
# FIXME: Replace `main' with a function in `-lhotp':
AC_CHECK_LIB([hotp], [main])
# Checks for header files.
AC_CHECK_HEADERS([fcntl.h limits.h stddef.h stdint.h stdlib.h string.h sys/time.h unistd.h])
# Checks for typedefs, structures, and compiler characteristics.
AC_HEADER_STDBOOL
AC_TYPE_OFF_T
AC_TYPE_PID_T
AC_TYPE_SIZE_T
AC_TYPE_SSIZE_T
# Checks for library functions.
AC_FUNC_MALLOC
AC_FUNC_REALLOC
AC_CHECK_FUNCS([memset strchr strdup strerror strstr strtol strtoul])
AC_CONFIG_FILES([makefile])
AC_PREIX_CONFIG_H(hotplugin)
AC_OUTPUT
When running autoconf in that project, I get the error:
configure.ac:35: error: possibly undefined macro: AC_PREIX_CONFIG_H
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
And my tool lists:
autoconf (GNU Autoconf) 2.63
autoscan (GNU Autoconf) 2.63
autoheader (GNU Autoconf) 2.63
m4 (GNU M4) 1.4.13
libtoolize (GNU libtool) 2.2.6b
You typoed the macro: AC_PREIX_CONFIG_H does not exist; AC_PREFIX_CONFIG_H used to, but it's obsolete, the correct one is AX_PREFIX_CONFIG_H.
Also if you want to use this macro you should look at how to use external macro files (full disclosure: I wrote that documentation.)
Related
I'm using link-time optimisation (LTO) in a project that compiles under both GCC and Clang and builds a static library. It's working with GCC 4.8, but GCC 5.4 makes thin LTO objects and when automake tries to build the static library with ar it fails, because it needs the wrapper script gcc-ar.
Is there a good example I can look at for how to make automake use gcc-ar instead of ar (and similarly for gcc-ranlib)? I can probably hack something in, but ideally it should:
Use the appropriate tools for the compiler (Clang has its own instructions).
Work even if the user overrides the compiler to one that isn't the system default.
Work when cross compiling
You can override the default tools used by calling
./configure AR=gcc-ar RANLIB=gcc-ranlib
I'm afraid for ./configure to pick them up by default, autoconf/automake will have to be fixed to know about those in the default set of checks.
Use this:
AC_ARG_VAR([AR], [AR command (default is gcc-ar)])
AC_CHECK_TOOL([AR], [gcc-ar])
AC_ARG_VAR([RANLIB], [RANLIB command (default is gcc-ranlib)])
AC_CHECK_TOOL([RANLIB], [gcc-ranlib])
AC_ARG_VAR is there just to document it, when invoking ./configure --help.
AC_CHECK_TOOL is used for these tools, instead of AC_CHECK_PROGS, so the right version is used when cross-compiling.
You can still override AR, RANLIB when invoking ./configure.
To fallback to regular ar and regular ranlib, you can use AC_CHECK_TOOLS instead:
AC_CHECK_TOOLS([AR], [gcc-ar ar])
An optional third argument can be set to something like : so you can test if none of the tools were found:
AC_CHECK_TOOLS([AR], [gcc-ar ar], [:])
AS_VAR_IF([AR], [:], AC_MSG_ERROR([could not find AR tool.]))
For Clang, they follow a different naming convention: llvm-ar, llvm-ranlib, llvm-objcopy, etc. I'll be using two helper macros.
First, we define MY_CHECK_TOOL_PREFIX, using AX_COMPILER_VENDOR, this will try to guess what tool prefix to use; it can be overridden with the TOOL_PREFIX variable. It will test the compiler for the current language (defaults to C); make sure to call AC_LANG(C++) beforehand if needed. It's used by the next macro, you don't need to call it manually.
AC_DEFUN([MY_CHECK_TOOL_PREFIX],
[
AC_REQUIRE([AX_COMPILER_VENDOR])
AC_ARG_VAR([TOOL_PREFIX], [tool prefix (gcc, llvm)])
AC_MSG_CHECKING([toolchain prefix])
# only convert vendor to prefix if not already set
AS_VAR_SET_IF([TOOL_PREFIX],
[],
[
AS_CASE([${ax_cv_[]_AC_LANG_ABBREV[]_compiler_vendor}],
[gnu], [TOOL_PREFIX="gcc"],
[clang], [TOOL_PREFIX="llvm"],
[TOOL_PREFIX="unknown"])
])
AC_MSG_RESULT([$TOOL_PREFIX])
])
Then comes the macro you'll be using: MY_CHECK_TOOL. The default action, if not variant of the tool is found, is to abort.
dnl MY_CHECK_TOOL(TOOL, PROGRAM-TO-CHECK, [ACTION-IF-NOT-FOUND])
AC_DEFUN([MY_CHECK_TOOL],
[
AC_REQUIRE([MY_CHECK_TOOL_PREFIX])
AC_ARG_VAR($1, [$1 command (default is TOOL_PREFIX-$2, $2)])
AC_CHECK_TOOLS($1, [${TOOL_PREFIX}-$2 $2], [:])
AS_VAR_IF($1, [:],
[m4_ifblank($3,
[AC_MSG_ERROR([could not find $1])],
$3)])
])
You can save both in a my_prefix_tools.m4 file in your M4 dir, if you don't want to clutter your configure.ac.
And here's how you'd use it in configure.ac:
AC_PROG_CXX
AC_LANG(C++)
MY_CHECK_TOOL([AR], [ar])
MY_CHECK_TOOL([RANLIB], [ranlib])
MY_CHECK_TOOL([OBJCOPY], [objcopy])
MY_CHECK_TOOL([NM], [nm])
When running ./configure where g++ is the default C++ compiler, this is the output:
checking for C++ compiler vendor... gnu
checking toolchain prefix... gcc
checking for gcc-ar... gcc-ar
checking for gcc-ranlib... gcc-ranlib
checking for gcc-objcopy... no
checking for objcopy... objcopy
checking for gcc-nm... gcc-nm
And when running ./configure CXX=clang++, this is the output:
checking for C++ compiler vendor... clang
checking toolchain prefix... llvm
checking for llvm-ar... llvm-ar
checking for llvm-ranlib... llvm-ranlib
checking for llvm-objcopy... llvm-objcopy
checking for llvm-nm... llvm-nm
I'm trying to install Boogie (22 Oct 2012 version) on Mac OS X 10.8. I downloaded the Boogie from here, and installed Mono 3.4.0. Boogie without the verify option worked fine for me.
Next, I needed to install Z3. I tried the nightly OS X build because I thought that would be simplest, but Boogie gave a lot of errors along the lines of:
Prover error: line 5 column 22: the parameter 'model_v2' was renamed to 'model.v2', invoke 'z3 -p' to obtain the new parameter list, and 'z3 -pp:model.v2' for the full description of the parameter
So I tried to download the source for Z3 version 4.1 and compile it. I ran autoconf, and configure without any problems, but make had many errors:
$ autoconf
$ ./configure
checking for dos2unix... /usr/local/bin/dos2unix
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether make sets $(MAKE)... yes
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated
checking how to run the C++ preprocessor... g++ -E
configure: creating ./config.status
config.status: creating Makefile
Z3 was configured with success.
Host platform: osx
Arithmetic: internal
Type 'make' to compile Z3.
$ make
Makefile:271: obj/external/act_cache.d: No such file or directory
Makefile:271: obj/external/add_bounds.d: No such file or directory
Makefile:271: obj/external/add_bounds_tactic.d: No such file or directory
Makefile:271: obj/external/aig.d: No such file or directory
....
(many like this)
....
Makefile:273: obj-test/external/array_property_expander.d: No such file or directory
Makefile:273: obj-test/external/arith_rewriter.d: No such file or directory
Makefile:273: obj-test/external/arith_simplifier_plugin.d: No such file or directory
Makefile:273: obj-test/external/ast.d: No such file or directory
....
(and more like this)
....
Making dependency file 'obj-test/external/bits.d' ...
clang: warning: argument unused during compilation: '-fopenmp'
clang: warning: argument unused during compilation: '-mfpmath=sse'
In file included from test/bits.cpp:5:
In file included from lib/mpz.h:29:
lib/z3_omp.h:23:9: fatal error: 'omp.h' file not found
#include"omp.h"
^
1 error generated.
Any idea what could be wrong? My g++ version is:
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
EDIT: I followed Christoph's suggestions, and I could start the build successfully, but at some point I got the following errors:
clang: warning: argument unused during compilation: '-mfpmath=sse'
lib/hwf.cpp:27:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas]
#pragma STDC FENV_ACCESS ON
^
In file included from lib/hwf.cpp:50:
/usr/bin/../lib/clang/5.0/include/emmintrin.h:1388:22: error: expected expression
return (__m128)__in;
^
/usr/bin/../lib/clang/5.0/include/emmintrin.h:1394:23: error: expected expression
return (__m128i)__in;
^
/usr/bin/../lib/clang/5.0/include/emmintrin.h:1400:23: error: expected expression
return (__m128d)__in;
^
/usr/bin/../lib/clang/5.0/include/emmintrin.h:1406:23: error: expected expression
return (__m128i)__in;
^
/usr/bin/../lib/clang/5.0/include/emmintrin.h:1412:22: error: expected expression
return (__m128)__in;
^
/usr/bin/../lib/clang/5.0/include/emmintrin.h:1418:23: error: expected expression
return (__m128d)__in;
^
1 warning and 6 errors generated.
Any ideas?
This one is a bit tricky as Boogie doesn't support the new Z3 (see also here), but the old 4.1.2 version of Z3 doesn't support the new compiler (clang) on OSX 10.9. This is mainly because clang lacks support for OpenMP. We can build this version of Z3 without support for OpenMP though, by adding -D_NO_OMP_ to the CPPFLAGS line in the Makefile, or by running
CPPFLAGS=-D_NO_OMP_ LDFLAGS=-stdlib=libstdc++ ./configure
on the command line (the LDFLAGS setting is required because clang selects an unsuitable standard C++ library by default; see here for details). We then need to replace all occurrences of -fopenmp in the Makefile, e.g., by running
sed -i '' "s/-fopenmp//" Makefile
Once that is done, Z3 4.1.2 should build successfully.
I am trying to enable c++11 for gcc 4.6; I am using autconf and I added following to my configure.ac file
AC_PREREQ(2.61)
AC_INIT(SOLARCORE, 1.0.0, BUG-REPORT-ADDRESS)
AM_INIT_AUTOMAKE([1.10 no-define foreign])
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_SRCDIR([src/threading/node.h])
AC_CONFIG_HEADER([config.h])
AC_OUTPUT([Makefile src/threading/Makefile])
# Checks for programs.
AC_PROG_CXX
AC_PROG_CC
#AC_LANG_PUSH([C++])
AC_LANG([C++])
AC_GNU_SOURCE
AX_CXX_COMPILE_STDCXX_11(,[mandatory])
CXXFLAGS='-Wall -std=gnu++0x'
AC_TYPE_SIZE_T
AC_OUTPUT
I am getting following error
./configure: line 4949: syntax error near unexpected token ,mandatory'
./configure: line 4949:AX_CXX_COMPILE_STDCXX_11(,mandatory)'
I also tried AX_CXX_COMPILE_STDCXX_11([ext],[mandatory])
I want to enable C++11 so that I can use it. I tried without AX_CXX_COMPILE_STDCXX_11 and with just CXXFLAGS in my Makefile but it is not working. So please help. THanks.
Found the answer: Recent version of AX_CXX_COMPILE_STDCXX_11 doesnt need a argument.
Are you sure you have the latest version of the macro? Judging from the history available from the autoconf archive, the original version of the macro only expected one argument, not two. If you've not got the second or third revisions of the test, that might account for your trouble.
I am trying to compile some code using autotools and am getting stuck when trying to include boost::date-time and boost::regex. I was given an configure.in file that defines that looks for boost::date-time this way
AC_CHECK_LIB(boost_date_time-gcc-mt, main, , [
AC_CHECK_LIB(boost_date_time-mt, main, , [
AC_CHECK_LIB(boost_date_time, main, , [
AC_MSG_ERROR("Linking against boost::date-time library failed.")])
])
])
which appears to be the standard way according to google. But when I run autoreconf:
$ autoreconf -f -s -i
libtoolize: putting auxiliary files in `.'.
libtoolize: linking file `./ltmain.sh'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
and ./configure:
$ CXXFLAGS="-g -w" ./configure --prefix=$INSTALL_PATH
...
checking for main in -lboost_date_time-gcc-mt... no
checking for main in -lboost_date_time-mt... no
checking for main in -lboost_date_time... no
configure: error: "Linking against boost::date-time library failed."
It cannot be found. I know they are there cause I compiled boost 1.53 from scratch. What could be an issue here?
Thanks a lot in advance.
There's an excellent boost.m4 macro. You can copy it into a top level ./m4 directory.
AC_CONFIG_MACRO_DIR([m4]) in configure.ac
ACLOCAL_AMFLAGS = -I m4 --install in the top-level Makefile.am
invoke aclocal with aclocal -I m4 --install
It's very easy to use the results in configure.ac, e.g., for Boost.Filesystem:
BOOST_REQUIRE([1.53], [ACTION-IF-NOT-FOUND])
AC_SUBST(BOOST_CPPFLAGS)
MY_PROJECT_CPPFLAGS+="$BOOST_CPPFLAGS"
BOOST_FILESYSTEM([mt])
AC_SUBST(BOOST_FILESYSTEM_LIBS)
AC_SUBST(BOOST_FILESYSTEM_LDFLAGS)
MY_PROJECT_LIBFLAGS+="$BOOST_FILESYSTEM_LDFLAGS $BOOST_FILESYSTEM_LIBS"
It will even add dependencies like Boost.System.
There are macros at the GNU Autoconf Archive for both boost::date-time and boost::regex. Perhaps they would be more suitable.
It cannot be found. I know they are there cause I compiled boost 1.53 from scratch. What could be an issue here?
You'll have to consult config.log to know that for sure. Since you are looking for the main functions in those libs (which aren't in those libs, but that's another issue), the AC_CHECK_LIB tests generate invalid C++ code, and that may be your problem.
I'm having trouble building a little program that uses Boost.Test on my Mac with a Boost installed by MacPorts at /opt/local/lib/
Here's my minimal source file, test.cpp:
#define BOOST_TEST_MODULE MyTest
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_CASE(test1) {
}
and my CMakeLists.txt:
cmake_minimum_required(VERSION 2.6)
project (test)
find_package(Boost COMPONENTS unit_test_framework REQUIRED)
add_executable(test test.cpp)
and an excerpt of from make VERBOSE=1:
[100%] Building CXX object CMakeFiles/test.dir/test.cpp.o
g++ -o CMakeFiles/test.dir/test.cpp.o -c /Users/exclipy/Code/cpp/inline_variant/question/test.cpp
Linking CXX executable test
"/Applications/CMake 2.8-5.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/test.dir/link.txt --verbose=1
g++ -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/test.dir/test.cpp.o-o test
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
"vtable for boost::unit_test::unit_test_log_t", referenced from:
boost::unit_test::unit_test_log_t::unit_test_log_t() in test.cpp.o
boost::unit_test::unit_test_log_t::~unit_test_log_t() in test.cpp.o
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
As you can see, it doesn't know how to link to Boost library. So I try adding to CMakeLists.txt:
target_link_libraries(test boost_unit_test_framework)
But I just get:
g++ -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/test.dir/test.cpp.o-o test -lboost_unit_test_framework
ld: library not found for -lboost_unit_test_framework
From lots of trial and error, I've found that manually running this works:
$ g++ test.cpp -L/opt/local/lib -lboost_unit_test_framework -DBOOST_TEST_DYN_LINK
But after hours of fiddling, I can't get it to build from CMake. I don't care whether it links dynamically or statically, I just want it to work.
You need to tell CMake where to find the boost libraries (the -L/opt/local/lib in your g++ line). You can accomplish this by adding the following line (if you had no problem with find_package):
link_directories ( ${Boost_LIBRARY_DIRS} )
before add_executable.
Another alternative is using the single-header variant of the UTF. This variant is really simple (you only need to include <boost/test/included/unit_test.hpp> but it has a major drawback in its considerable increase in build time.
The find_package(Boost COMPONENTS ...) call collects the required link libraries for the searched Boost components (e.g.,unit_test_framework) in the CMake variable Boost_LIBRARIES.
To get rid of the link error, add:
target_link_libraries(test ${Boost_LIBRARIES})
EDIT 2020-02
The details of building a Boost.Test module are on the documentation here and covered with many examples on the documentation. Usually if main is not found, this might be due to:
mixing static and shared library versions of Boost.Test (the linker prefers shared libraries)
improper definitions of the BOOST_TEST_MODULE and/or BOOST_TEST_DYN_LINK macros: depending on those, the Boost.Test framework will define (correctly) a main or not.
Previous (wrong) answer
Well here, the problem is not that cmake does not find the boost_unit_test_framework library, but rather that this specific library does not contain the main entry point for running the binary.
In fact, you should link against ${Boost_TEST_EXEC_MONITOR_LIBRARY} since it contains the proper definitions. You should also avoid defining the macro BOOST_TEST_DYN_LINK.