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.
Related
I am installing packages on a machine without internet access and want to install automake. But I get following error message:
WARNING: 'makeinfo' is missing on your system.
You should only need it if you modified a '.texi' file, or
any other file indirectly affecting the aspect of the manual.
You might want to install the Texinfo package:
<http://www.gnu.org/software/texinfo/>
The spurious makeinfo call might also be the consequence of
using a buggy 'make' (AIX, DU, IRIX), in which case you might
want to install GNU make:
http://www.gnu.org/software/make/
Therefore I try to make texinfo where I get following error:
WARNING: 'aclocal-1.16' is missing on your system.
You should only need it if you modified 'acinclude.m4' or
'configure.ac' or m4 files included by 'configure.ac'.
The 'aclocal' program is part of the GNU Automake package:
<https://www.gnu.org/software/automake>
It also requires GNU Autoconf, GNU m4 and Perl in order to run:
<https://www.gnu.org/software/autoconf>
<https://www.gnu.org/software/m4/>
<https://www.perl.org/>
Apparently both programs need each other, which I don't understand.
Help is appreciated a lot. Thanks!
I have an difficult relationship with the GNU autotools, especially libtool. But because they kick ass when it comes to portability and cross compilation I started using them again.
Unfortunately I can't get libtool to build proper windows DLLs. Yet with vanilla make gcc
will happily build the DLL for me.
For example:
LIBEXT = .dll
pkzo$(LIBEXT): $(patsubst %.cpp, %.o, $(pkzo_SOURCES)) resources.o
$(CXX) -shared -fPIC $(CXXFLAGS) $^ $(LDFLAGS) -Wl,--out-implib=libpkzo.lib -o $#
Will haily build a DLL and import library. (Even without any annoying decelspec).
Yet if I use libtool like so:
lib_LTLIBRARIES = libpkzo.la
libpkzo_la_CXXFALGS = ...
libpkzo_la_LDADD = ...
libpkzo_la_SOURCES = ...
Libtool comes complaining:
*** Warning: linker path does not have real file for library -lSDL2main.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libSDL2main and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/local/lib/libSDL2main.a
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
Well guess what libSDL2main.a is a static library and has no DLL.
It there a way to build a DLL with automake not using libtool or telling libtool to stop making a fuss about nothing?
PS: Before anyone mentions it, I am configuring libtool with LT_INIT([shared static win32-dll])
For the first problem, make sure you have a shared version of the SDL library installed.
If you absolutely must link your DLL to static libs, you can trick libtool into doing it by editing the libtool script. E.g., if you want all of the dependent libs statically linked to your DLL, you can do that by putting this at the end of your configure.ac:
sed -i '/^whole_archive_flag_spec=/s/"$/ \\${wl}-static"/' libtool
Now, this is a gross hack and relies on the particular way that libtool builds command lines right now, so there's no guarantee that it will continue to work---but it does work with libtool 2.4.2. Since you have just one library which you want statically linked, you could achieve that by applying sed a bit differently. Probably you'll want
sed -i '/^whole_archive_flag_spec=/s/"$/ \\${wl}-static \\${wl}-lSDL2main \\${wl}-shared"/' libtool
in order to keep shared linking with whatever other shared libs you have, and then you'll need to take -lSDL2main out of wherever else you have it. This is gimpy, but the thing you're trying to do is also gimpy and libtool isn't made for this.
For the second problem, add -no-undefined to libpkzo_la_LDFLAGS.
Description:
I am doing Customization for tacacs+ server open source code. While packaging
i am tring to run configure to genrate Makefile.
Note: In open source tacacs+ tar is using autoconf 2.63 & on my build machine is having
2.67 autoconf version. Only this the env diff.
But get AC_DEFINE() undefined error as below:
d001:~/srcsvn/workspace_main_7.40_04102013_64bit/NMD2/64bit/os/usr.local/tacplus_merger/src/tacacs+-4.0.4.19.orig$ autoreconf --force --install
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `cfgaux'.
libtoolize: copying file `cfgaux/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.
configure.in:45: error: possibly undefined macro: AC_DEFINE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
Check the file configure.in in line 45 and above and scan for pkg-config calls.
Then check if you have it installed (just type pkg-config). If this fails, you are missing pkg-config. Apply your distros way of installing software (rpm, apt-get, pacman, bee) and install the missing pkg-config package.
This happens all too often when something unrelated to it is misquoting the usage of the macro.
While it does not help much without knowing what the configure.ac looks like, you should observe the lines around line 45, rather than on that line, to figure out what's going wrong. Sometimes it can be just a misplaced [] quote.
I am trying to get libtool working on my MacOS 10.8.3 machine. Because everything Apple ships is out of date, I'm using macports. I have up-to-date versions:
libtool (GNU libtool) 2.4.2
automake (GNU automake) 1.13.1
autoconf (GNU Autoconf) 2.69
It's all installed in /opt.
Here is configure.ac:
AC_INIT([Hello], [0.1], [bug-report#hello.example.com], [hello], [http://hello.example.com/])
AC_PREREQ([2.59])
AM_INIT_AUTOMAKE([1.10 no-define])
LT_INIT
AC_CONFIG_HEADERS([config.h])
AC_PROG_CXX
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
Here is Makefile.am:
lib_LTLIBRARIES = libsomething-1.0.la
libsomething_1_0_la_SOURCES = something.cc
bin_PROGRAMS = hello
hello_SOURCES = hello.h hello.cc main.cc
Running glibtoolize produces this error:
glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
glibtoolize: rerunning glibtoolize, to keep the correct libtool macros in-tree.
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
When I add this line to Makefile.am:
ACLOCAL_AMFLAGS="-I m4"
I get this error;
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
If I change it to this:
ACLOCAL_AMFLAGS="-Im4"
I get the same error:
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
The second error I get is:
configure.ac:5: error: required file '../ltmain.sh' not found
How do I make these errors go away?
It needs to be:
ACLOCAL_AMFLAGS = -I m4
in Makefile.am and:
AC_CONFIG_MACRO_DIR([m4])
in configure.ac. You do have an m4 directory, at $(top_srcdir) right?
Maybe I'm late to the part, the answer of #ldav1s is the solution, BUT I still had issues.
After some Googling, I found this: https://pete.akeo.ie/2010/12/that-darn-libtoolize-acconfigmacrodirm4.html
So, ldav1's answer + this worked for me:
dos2unix Makefile.am
And now it works!
While building ARM toolchain , I got the following error
checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory `<path>/gcc-4.3.2-arm-elf'
make: *** [all] Error 2
what might be the problem?
Did you read http://gcc.gnu.org/wiki/FAQ#configure_suffix ?
Have you installed GMP, MPFR and MPC? Are they in your library search path?
See http://gcc.gnu.org/wiki/InstallingGCC and make sure you've followed the basic instructions. By far the simplest way to build GCC (including as a cross compiler) is to follow these instructions:
Alternatively, after extracting the GCC source archive, simply run the ./contrib/download_prerequisites script in the GCC source directory. That will download the support libraries and create symlinks, causing them to be built automatically as part of the GCC build process.
"*Building GCC is not trivial, but is not difficult if you follow the instructions carefully.
Many people rush into trying to build it without reading the installation docs properly and make one or more of these common mistakes:
1) do not run ./configure from gcc src dir (this is not supported) => you need to run configure from outside the gcc source directory
2) Note: if GCC links dynamically to the prerequisite libs (GMP/MPFR/MPC) then the shared libraries must be in the dynamic linker's path (LD_LIBRARY_PATH), both when building gcc and when using the installed compiler.*"
Simple example (without dynamic link to GMP/MPFR/MPC):
tar xzf gcc-4.8.0.tar.gz
cd gcc-4.8.0
./contrib/download_prerequisites
cd ..
mkdir objdir
cd objdir
$PWD/../gcc-4.8.0/configure --prefix=/opt/gcc-4.8.0
make
make install
Sources:
Advogato Doc -
GNU Doc
export LD_LIBRARY_PATH=/path/for/libraries:$LD_LIBRARY_PATH
path/for/libraries is where the GMP MPFR and MPC libraries are present.
I was compiling GCC on ubuntu 12.04 and these linraries present in the path /usr/local/lib