1

I'm in the early stages of adding Autotools support to a C++ library. At this point I'm running autoreconf with the following configuration.

$ cat Makefile.am
AUTOMAKE_OPTIONS = foreign
bin_PROGRAMS=cryptest

$ cat configure.ac
AC_INIT(Crypto++, 6.0, http://www.cryptopp.com/wiki/Bug_Report)
AM_INIT_AUTOMAKE
AC_PROG_CXX
AC_CONFIG_FILES([Makefile])

It is producing:

$ autoreconf --install --force
/usr/share/automake-1.15/am/depend2.am: error: am__fastdepCC does not appear in AM_CONDITIONAL
/usr/share/automake-1.15/am/depend2.am:   The usual way to define 'am__fastdepCC' is to add 'AC_PROG_CC'
/usr/share/automake-1.15/am/depend2.am:   to 'configure.ac' and run 'aclocal' and 'autoconf' again
Makefile.am: error: C source seen but 'CC' is undefined
Makefile.am:   The usual way to define 'CC' is to add 'AC_PROG_CC'
Makefile.am:   to 'configure.ac' and run 'autoconf' again.
autoreconf: automake failed with exit status: 1

I'm trying to tackle the error: C source seen but 'CC' is undefined issue first.

Conventional wisdom based on mailing list reading is to add AC_PROG_CC to work around the issue. I really don't feel like working around the problems C++ flags are going to cause a C compiler, especially on compilers like IBM's xlc and Sun's cc. It also seem wrong given GNU is all about user choice.

How do I tell Autotools this project is a C++ project, and it should not do anything with C or a C compiler?

Here are some of the issues it is causing.

$ egrep 'CC|CFLAGS' Makefile
COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \
        $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS)
...
LTCOMPILE = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
        $(LIBTOOLFLAGS) --mode=compile $(CC) $(DEFS) \
        $(AM_CFLAGS) $(CFLAGS)
...
CCLD = $(CC)
...
LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
        $(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \

$ autoreconf --version
autoreconf (GNU Autoconf) 2.69

$ autoconf --version
autoconf (GNU Autoconf) 2.69

$ automake --version
automake (GNU automake) 1.15
jww
  • 97,681
  • 90
  • 411
  • 885
  • Maybe figure out, why the error message comes up at all. See https://lists.gnu.org/archive/html/automake/2003-01/msg00053.html for an example. – Olaf Dietsche Nov 01 '17 at 17:13
  • Here's a similar problem, the other way round: http://gnu-automake.7480.n7.nabble.com/source-code-type-detection-td4059.html – Olaf Dietsche Nov 01 '17 at 17:15
  • Thanks Olaf. An `ls *.c` results in `ls: cannot access '*.c': No such file or directory`; and `ls -1 *.cpp | wc -l` results in `155`. Its kind of a mystery (to me) why Autotools wants a C compiler for anything. – jww Nov 01 '17 at 17:19
  • It's possible their C++ macros still search for [cfront](https://en.wikipedia.org/wiki/Cfront) type compilers which would be problematic not to have a search for the C compiler. – ldav1s Nov 01 '17 at 23:26

1 Answers1

3

When you define a program like bin_PROGRAMS=cryptest, automake looks for cryptest_SOURCES to figure out what are the source files for cryptest. If you don't define cryptest_SOURCES, automake will automatically generate one by appending ".c" (by default) to the program name, e.g. as if you had defined cryptest_SOURCES=cryptest.c. To override the default, you could explicitly define the source for each of your programs, e.g. cryptest_SOURCES=cryptest.cpp, or you could define AM_DEFAULT_SOURCE_EXT=.cpp to make all automatically generated source file names end in ".cpp" instead of ".c".

Of course, if your source name doesn't match the program name, or there are multiple sources (including any header files you want to be included by "make dist"), you're going to need the explicit definition anyway, e.g. cryptest_SOURCES=cryptest.cpp cryptest-part2.cpp cryptest.h.

See: https://www.gnu.org/software/automake/manual/automake.html#Default-_005fSOURCES

Edited to add: Assuming you're going to be using AC macros to test features of the compiler, you're going to want to call AC_LANG([C++]) first (after AC_PROG_CXX) to tell autoconf that it should be testing the C++ compiler, not the C compiler.

Ken Keys
  • 226
  • 2
  • 4
  • Ugh, thanks Ken. Unfortunately, that did not work. The generated makefile includes `CC = gcc` and `CFLAGS =`. I even tried to remove it in `AC_CONFIG_COMMANDS` using `sed` in my [`configure.ac`](https://github.com/noloader/cryptopp-autotools/blob/master/configure.ac). No joy. – jww Nov 01 '17 at 23:18
  • Thanks Ken. I'm sorry to say I am still [witnessing the issue](https://pastebin.com/6Njg0KW4). Looking at the makefile its doing exactly what I wanted to avoid: its linking through `CC`, not `CXX`. I'm guessing the Autoconf guys have never actually tested a C++ project; otherwise it would have stuck out like a sore thumb and been fixed. I tried to `CC=/dev/null`, but it just broke things. – jww Nov 02 '17 at 19:26
  • I'm guessing this can't be fixed by work-arounds on my end. I'll just accept since you've spent so much time on the issue. If you want to try the real project, it can be found at [cryptopp-autotools](https://github.com/noloader/cryptopp-autotools). It has your changes applied. Thanks again. – jww Nov 02 '17 at 19:27