I'm trying to use the GNU autotools (autoconf, automake, etc) to work with a project I'm developing for C++. This is my first experience using those tools. I've gotten a very basic project to work with C source so I'm understanding the interactions. The problem that I'm having is getting the files to work with for C++ source using G++. Through my searching through online resources, I've found that supposedly the only thing I need to do is add the following to configure.in: AC_PROG_CXX That's on top of AC_PROG_C. However, after I add the line and then rerun autoconf and automake, then go through the make process, it still is looking to use gcc instead of g++ when compiling and there is an error. I'm curious if I'm missing a step. Any help would be appreciated.

What was the error? What is the extension you're using for your C++ source files? If you add "AC_LANG([C++])" some additional automake tests will use g++ rather than gcc, but that may not be what you're needing.

You might also want to run the autotools programs again, just in-case something was left behind:
aclocal
autoconf --force
automake --add-missing --force-missing
./configure

Hmm...that did not work for some reason. I have one source that is main.cpp and is just a main function that returns nothing. The specific error that I am getting is:

"No rule to make target `main.c', needed by `main.o'. Stop."

I updated the configure.in file with AC_CONFIG_SRCDIR([src/main.cpp]) on top of AC_PROG_CXX.

I also updated the makefile within the source directory to build main.cpp instead of main.c. With all that done previously, I get the above error message.

Based on your recommendations I added AC_LANG([C++]) in the configure.in file as well and still got no dice. I reran aclocal, autoconf, automake with the mentioned options and I still get the error. It seems like I'm forgetting something where either main.c is cached somewhere in some file. So I decided to delete all the unneccessary files and start over and I'm still getting the same error.

Your problem is likely within Makefile.am/Makefile.in/Makefile rather than configure.in/configure.ac. If Makefile.am is correct, then one of its generated descendants is out-of-date. Automake converts Makefile.am to Makefile.in and your configure scripts converts Makefile.in to Makefile. Perhaps try removing Makefile.in and Makefile before generating everything to ensure they're up-to-date.

While it may not help you immediately, but when you run your configure script, enable maintain mode (./configure --enable-maintainer-mode) and it will watch for changes to files that cause generated files to need to be regenerated and automatically update then on the next call to make.

I removed all the generated Makefile's and configure files outside of configure.in and makefile.am before running it last time. I just decided to start over completely rewriting a minimum configure.in and makefile.am files and for some reason it works now. Thanks for the help.

Quote: Original post by pinkyandthebrain
"No rule to make target `main.c', needed by `main.o'. Stop."

That sounds like an out-of-date .dep file. Next time, try removing all .deps and regenerating them.

  > find . -name .deps -exec rm -rf {} \;  > ./config.status

This should force autoconf to regenerate all source dependencies again.

The problem you have there is (i believe) in your makefile, basically its telling you that
"No rule to make target `main.c', needed by `main.o'. Stop."

meaning you need to specify what to do to that file main.c in fact to any files with the extension .c
http://www.hsrl.rutgers.edu/ug/make_help.html

see the section Makefile Implicit Rules.

you need something like

.o.c:
$(CC) $(CFLAGS) -c $<

the rule tells make that to create a .o file from a .c it uses the c compiler (CC) with the flags (CFLAGS) with option -c the $< represents the current file of extension .c its working on.


I may be wrong or not im a little dusty :)

So I have everything working. I'm linking in external libraries and headers, recursively going through directories building what is needed. My only issue now is a deal with libtool. I'm wondering if there is a way to define where libtool exists. Right now based on the makefiles and automake it's looking for libtool in:

$(SHELL) $(top_builddir)/libtool

But it doesn't reside there. Outside of modifying the makefile, it seems like either this is a bug within libtool itself (I'm using version 1.5) or there should be a config option somewhere.

When you call libtoolize, it will install libtool in your project's root. I prefer to use libtoolize --copy for that extra touch of redistribution ease.

Quote: Original post by pinkyandthebrain
But it doesn't reside there. Outside of modifying the makefile, it seems like either this is a bug within libtool itself (I'm using version 1.5) or there should be a config option somewhere.

I suspect the latter: the autotools have been used by many many project sover many years. Someone would have noticed something fundamental like that by now if it were a bug in the autotools.

Your configure.ac file must contain directives to create libtool, such as the following.

AC_LIBTOOL_WIN32_DLL   # if you're going to build on a Win32 platformAC_PROG_LIBTOOL        # add libtool to autotools suiteAC_SUBST(LIBTOOL_DEPS) # force regeneration of libtool  if necessary

The libtool script is generated automatically by the autotools. If you're not already doing so, you need to use autoreconf to run the autotools on your source. You should not actually run any of the autotools directly, since there are various interdependencies that are easy to get wrong.

The general flow for build software from your VCS (where you do not normally store any Makefiles, Makefile.ins, or configure files, since they're generated from sources) is as follows.

> autoreconf -ifv> ./configure> make