I have the following source tree for a C++ library: - src/foo - src/foo.cxx where the former file is a header, and the latter contains the code. The Makefile.am for this is: include_HEADERS = src/foo lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = \ src/foo.cxx Now, everytime I modify src/foo.cxx: $ make make all-am make[1]: Entering directory `/tmp/a' depbase=`echo src/foo.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ g++ -DHAVE_CONFIG_H -I. -g -O2 -MT src/foo.o -MD -MP -MF $depbase.Tpo -c -o src/foo.o src/foo.cxx &&\ mv -f $depbase.Tpo $depbase.Po gcc src/foo.o -o src/foo /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/crt1.o(.text+0x20): error: undefined reference to 'main' collect2: error: ld returned 1 exit status make[1]: *** [src/foo] Error 1 rm src/foo.o make[1]: Leaving directory `/tmp/a' make: *** [all] Error 2 Afterwards (and after recreating the header file it removed), successive make calls work as expected building the shared library.
To reproduce: git clone https://bitbucket.org/mgorny/automake-cxx-bug.git cd automake-cxx-bug autoreconf -vi ./configure --disable-static make # compiles fine touch src/foo.cxx make # fails
'emerge --info' will be required. The problem seems to be centered on non-recursive nature of this file, but while I get a problem with this test case, it's a different problem: src/foo.cxx:5:1: fatal error: opening dependency file .deps/src/foo.Tpo: No such file or directory Also, I'll get this problem even with automake 1.11.6.
Oops, correction: if the testcase is transformed into a recursive project, I'm getting the same problem as in the description. Still, happens even with 1.11.6.
this really belongs on the automake lists
(In reply to comment #2) > The problem seems to be centered on non-recursive nature of this file, but > while I get a problem with this test case, it's a different problem: > src/foo.cxx:5:1: fatal error: opening dependency file .deps/src/foo.Tpo: No > such file or directory This is another symptom of the same issue. If you run configure --disable-dependency-tracking or built the example files in many steps, you can get to the worse -- removal -- case.
(In reply to comment #4) > this really belongs on the automake lists Does the bug-automake@ list require subscription? Does it reply anyhow that message is in some queue or was rejected, or something like that? Upstream doesn't care enough to publish that information, and I'm wondering if my morning mail got there at all.
Write to automake-devel@
(In reply to comment #7) > Write to automake-devel@ Is there such a list? I can't reach it via the archives.
Sorry got the address wrong automake@gnu.org
