GNU bug report logs - #12142
automake tries to compile a program when 'foo' and 'foo.cxx' exist (though the former is header)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12142 in the body.
You can then email your comments to 12142 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michał Górny <mgorny <at> gentoo.org>
To: bug-automake <at> gnu.org
Subject: automake tries to compile a program when 'foo' and 'foo.cxx' exist
	(though the former is header)
Date: Sun, 5 Aug 2012 11:45:51 +0200

[Message part 1 (text/plain, inline)]

autoconf: 2.69
automake: 1.12.2
libtool: 2.4.2

Hello,

I was writing a C++ library and I think I hit a pretty ugly bug within
automake. My library was structured like the following:

- src/foo (the header file),
- src/foo.cxx (the code).

These files assemble a library, let's call it libfoo.la.

The problem is that every time I modify src/foo.cxx and call 'make',
automake first (correctly) compiles the library, and then mistakenly
tries to compile and link it into a program src/foo, either effectively
overwriting or removing my header file, or failing early due to
missing dependency file.

What's interesting, 'make' calls not following src/foo.cxx changes work
correctly; just the one after modifying src/foo.cxx fails.

Here are the minimal configure.ac & Makefile.am files with which I can
reproduce the issue:


configure.ac:

AC_PREREQ([2.60])
AC_INIT([foo], [0])
AM_INIT_AUTOMAKE([1.6 foreign])

AC_PROG_CXX
LT_INIT

AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT


Makefile.am:

include_HEADERS = src/foo
lib_LTLIBRARIES = libfoo.la

libfoo_la_SOURCES = src/foo.cxx


I've also prepared a git repository with the simple test case:

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


Related Gentoo bug report:
https://bugs.gentoo.org/show_bug.cgi?id=429972

-- 
Best regards,
Michał Górny

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at 12142 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Michał Górny <mgorny <at> gentoo.org>
Cc: 12142 <at> debbugs.gnu.org
Subject: Re: bug#12142: automake tries to compile a program when 'foo' and
	'foo.cxx' exist (though the former is header)
Date: Mon, 06 Aug 2012 09:38:08 +0200

tags 12142 notabug
thanks

On 08/05/2012 11:45 AM, Michał Górny wrote:
> autoconf: 2.69
> automake: 1.12.2
> libtool: 2.4.2
>
Also, which version of make are you using?

> Hello,
> 
> I was writing a C++ library and I think I hit a pretty ugly bug within
> automake.
>
What you describe below is not an Automake bug, but an unexpected interaction
with the GNU make built-in rules.  That is, GNU make contains (among other
stuff) a built-in rule to compile programs from a C++ source files:
<http://www.gnu.org/software/make/manual/make.html#Catalogue-of-Rules>
and that is being somehow invoked as an unindented consequence of your
declarations.  More details below.

> My library was structured like the following:
> 
> - src/foo (the header file),
>
Why not simply using a more usual name like 'foo.h' for 'foo.hxx'?
That would be unlikely to trigger unexpected problems in the first
place ...

> - src/foo.cxx (the code).
> 
> These files assemble a library, let's call it libfoo.la.
> 
> The problem is that every time I modify src/foo.cxx and call 'make',
> automake
>
No, automake is doing nothing at this point.  It's make that does the
building and compiling, using both the instructions given in the
Automake-generated Makefile and its own built-in rules.  And it's one
the latter that is wreaking havoc here.

 first (correctly) compiles the library, and then mistakenly
> tries to compile and link it into a program src/foo, either effectively
> overwriting or removing my header file, or failing early due to
> missing dependency file.
>
I guess this doesn't happen if you run make with the '--no-builtin-rules'
option.  And in fact ...

> What's interesting, 'make' calls not following src/foo.cxx changes work
> correctly; just the one after modifying src/foo.cxx fails. 
> I've also prepared a git repository with the simple test case:
> 
> 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
>
... I've tried this out and verified that my diagnosis is correct.

Bottom line: to avoid the issue, either rename the header file (the
sanest thing to do IMO), or ensure make gets always run with the
'--no-builtin-rules' option.

Regards,
  Stefano

Message #11 received at 12142 <at> debbugs.gnu.org (full text, mbox):

From: Jack Kelly <jack <at> jackkelly.name>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Michał Górny <mgorny <at> gentoo.org>, 12142 <at> debbugs.gnu.org
Subject: Re: bug#12142: automake tries to compile a program when 'foo' and
	'foo.cxx' exist (though the former is header)
Date: Mon, 6 Aug 2012 18:41:23 +1000

On Mon, Aug 6, 2012 at 5:38 PM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> On 08/05/2012 11:45 AM, Michał Górny wrote:
>> My library was structured like the following:
>>
>> - src/foo (the header file),
>>
> Why not simply using a more usual name like 'foo.h' for 'foo.hxx'?
> That would be unlikely to trigger unexpected problems in the first
> place ...

I have a feeling it's mimicking the way modern C++ prefers `#include
<iostream>' over `#include <iostream.h>'

I propose a third fix: move the header file into a separate directory
such as `include/' and add `-I$(top_srcdir)/include' to AM_CPPFLAGS.

Is it worth providing a way to disable implicit rules as an option to
AM_INIT_AUTOMAKE or via the AUTOMAKE_OPTIONS variable? It's not enough
to pass --no-builtin-rules to AM_MAKEFLAGS as I don't know if that's
portable. Further, the MAKEFLAGS only get propagated to submakes: the
top-level make has already loaded the implicit rules before it sees
MAKEFLAGS.

-- Jack

Message #14 received at 12142 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Jack Kelly <jack <at> jackkelly.name>
Cc: Michał Górny <mgorny <at> gentoo.org>, 12142 <at> debbugs.gnu.org
Subject: Re: bug#12142: automake tries to compile a program when 'foo' and
	'foo.cxx' exist (though the former is header)
Date: Mon, 06 Aug 2012 10:49:03 +0200

On 08/06/2012 10:41 AM, Jack Kelly wrote:
> On Mon, Aug 6, 2012 at 5:38 PM, Stefano Lattarini
> <stefano.lattarini <at> gmail.com> wrote:
>> On 08/05/2012 11:45 AM, Michał Górny wrote:
>>> My library was structured like the following:
>>>
>>> - src/foo (the header file),
>>>
>> Why not simply using a more usual name like 'foo.h' for 'foo.hxx'?
>> That would be unlikely to trigger unexpected problems in the first
>> place ...
> 
> I have a feeling it's mimicking the way modern C++ prefers `#include
> <iostream>' over `#include <iostream.h>'
> 
> I propose a third fix: move the header file into a separate directory
> such as `include/' and add `-I$(top_srcdir)/include' to AM_CPPFLAGS.
>
This seems unwarranted complexity just for the sake of an eye-candy
like "#include <foo>" over "#include <foo.h>".  But of course, that
is for the OP to decide.

> Is it worth providing a way to disable implicit rules as an option to
> AM_INIT_AUTOMAKE or via the AUTOMAKE_OPTIONS variable?
>
Trying to do that portably would be a nightmare I think (assuming it would
be possible at all).  OTOH, Automake-NG (the Automake fork whose generated
Makefiles only target GNU make) does that unconditionally (for performance
rather than correctness reasons):

 <http://lists.gnu.org/archive/html/automake-ng/2012-06/msg00294.html>

> It's not enough to pass --no-builtin-rules to AM_MAKEFLAGS as I don't
> know if that's portable.
>
In fact, it's not.

> Further, the MAKEFLAGS only get propagated to submakes: the
> top-level make has already loaded the implicit rules before it sees
> MAKEFLAGS.
> 
Luckily, with GNU make, you can append to MAKEFLAGS in the Makefile:

  MAKEFLAGS += -r

and have that take effect in the current make run as well.

Regards,
  Stefano

Message #17 received at 12142 <at> debbugs.gnu.org (full text, mbox):

From: Michał Górny <mgorny <at> gentoo.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 12142 <at> debbugs.gnu.org
Subject: Re: bug#12142: automake tries to compile a program when 'foo' and
	'foo.cxx' exist (though the former is header)
Date: Mon, 6 Aug 2012 11:20:22 +0200

[Message part 1 (text/plain, inline)]

On Mon, 06 Aug 2012 09:38:08 +0200
Stefano Lattarini <stefano.lattarini <at> gmail.com> wrote:

> On 08/05/2012 11:45 AM, Michał Górny wrote:
> > autoconf: 2.69
> > automake: 1.12.2
> > libtool: 2.4.2
> >
> Also, which version of make are you using?

GNU Make 3.82

> > My library was structured like the following:
> > 
> > - src/foo (the header file),
> >
> Why not simply using a more usual name like 'foo.h' for 'foo.hxx'?
> That would be unlikely to trigger unexpected problems in the first
> place ...

Because it is a legit name.

> > - src/foo.cxx (the code).
> > 
> > These files assemble a library, let's call it libfoo.la.
> > 
> > The problem is that every time I modify src/foo.cxx and call 'make',
> > automake
> >
> No, automake is doing nothing at this point.  It's make that does the
> building and compiling, using both the instructions given in the
> Automake-generated Makefile and its own built-in rules.  And it's one
> the latter that is wreaking havoc here.
> 
>  first (correctly) compiles the library, and then mistakenly
> > tries to compile and link it into a program src/foo, either
> > effectively overwriting or removing my header file, or failing
> > early due to missing dependency file.
> >
> I guess this doesn't happen if you run make with the
> '--no-builtin-rules' option.  And in fact ...

You are right indeed. However, AFAICS it's not exactly that simple.
Automake-generated Makefile first clears the default suffix list, then
explicitly adds new suffixes. Is there a reason for that?

Just removing the second '.SUFFIXES: ...' line helps indeed. Yet it's
probably not as portable as I'd like it to be. Still, it's worth
considering if the explicit suffix list is beneficial at all.

-- 
Best regards,
Michał Górny

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at 12142 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Michał Górny <mgorny <at> gentoo.org>
Cc: 12142 <at> debbugs.gnu.org
Subject: Re: bug#12142: automake tries to compile a program when 'foo' and
	'foo.cxx' exist (though the former is header)
Date: Tue, 07 Aug 2012 18:12:42 +0200

On 08/06/2012 11:20 AM, Michał Górny wrote:
> On Mon, 06 Aug 2012 09:38:08 +0200
> Stefano Lattarini <stefano.lattarini <at> gmail.com> wrote:
> 
>> On 08/05/2012 11:45 AM, Michał Górny wrote:
>>> autoconf: 2.69
>>> automake: 1.12.2
>>> libtool: 2.4.2
>>>
>> Also, which version of make are you using?
> 
> GNU Make 3.82
>
OK, as I assumed.

>>> My library was structured like the following:
>>>
>>> - src/foo (the header file),
>>>
>> Why not simply using a more usual name like 'foo.h' for 'foo.hxx'?
>> That would be unlikely to trigger unexpected problems in the first
>> place ...
> 
> Because it is a legit name.
>
I'm not contending that, but if it's causing problems due to bugs or
limitations of other important tools (GNU make, in this case), it would
be a good idea not to do so anyway IMHO.  Of course, you can agree to
differ on this.

>>> - src/foo.cxx (the code).
>>>
>>> These files assemble a library, let's call it libfoo.la.
>>>
>>> The problem is that every time I modify src/foo.cxx and call 'make',
>>> automake
>>>
>> No, automake is doing nothing at this point.  It's make that does the
>> building and compiling, using both the instructions given in the
>> Automake-generated Makefile and its own built-in rules.  And it's one
>> the latter that is wreaking havoc here.
>>
>>  first (correctly) compiles the library, and then mistakenly
>>> tries to compile and link it into a program src/foo, either
>>> effectively overwriting or removing my header file, or failing
>>> early due to missing dependency file.
>>>
>> I guess this doesn't happen if you run make with the
>> '--no-builtin-rules' option.  And in fact ...
> 
> You are right indeed. However, AFAICS it's not exactly that simple.
> Automake-generated Makefile first clears the default suffix list, then
> explicitly adds new suffixes. Is there a reason for that?
>
Portability to some vendor make I believe.

> Just removing the second '.SUFFIXES: ...' line helps indeed.
>
But that will cause the '.cxx.o' suffix rule to stop working with
some make implementations.  That's not something I prepared to
risk lightly.

> Yet it's
> probably not as portable as I'd like it to be. Still, it's worth
> considering if the explicit suffix list is beneficial at all.
>
I wouldn't if we could use pattern rules rather than suffix rules
(Automake-NG does exactly that).  But of course, they are not
portable :-(

Regards,
  Stefano

Message #25 received at 12142 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> elliptictech.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: Michał Górny <mgorny <at> gentoo.org>, 12142 <at> debbugs.gnu.org
Subject: Re: bug#12142: automake tries to compile a program when 'foo' and
	'foo.cxx' exist (though the former is header)
Date: Tue, 14 Aug 2012 16:21:13 -0400

On 2012-08-07 18:12 +0200, Stefano Lattarini wrote:
> On 08/06/2012 11:20 AM, Michał Górny wrote:
> > On Mon, 06 Aug 2012 09:38:08 +0200
> > Stefano Lattarini <stefano.lattarini <at> gmail.com> wrote:
> > 
> >> On 08/05/2012 11:45 AM, Michał Górny wrote:
[...]
> >>> My library was structured like the following:
> >>>
> >>> - src/foo (the header file),
[...]
> >>> - src/foo.cxx (the code).
> >>>
> >>> These files assemble a library, let's call it libfoo.la.
> >>>
> >>> The problem is that every time I modify src/foo.cxx and call 'make',
> >>> automake
> >>>
> >> No, automake is doing nothing at this point.  It's make that does the
> >> building and compiling, using both the instructions given in the
> >> Automake-generated Makefile and its own built-in rules.  And it's one
> >> the latter that is wreaking havoc here.
> >>
> >>  first (correctly) compiles the library, and then mistakenly
> >>> tries to compile and link it into a program src/foo, either
> >>> effectively overwriting or removing my header file, or failing
> >>> early due to missing dependency file.
> >>>
> >> I guess this doesn't happen if you run make with the
> >> '--no-builtin-rules' option.  And in fact ...
> > 
> > You are right indeed. However, AFAICS it's not exactly that simple.
> > Automake-generated Makefile first clears the default suffix list, then
> > explicitly adds new suffixes. Is there a reason for that?
> >
> Portability to some vendor make I believe.
> 
> > Just removing the second '.SUFFIXES: ...' line helps indeed.
> >
> But that will cause the '.cxx.o' suffix rule to stop working with
> some make implementations.  That's not something I prepared to
> risk lightly.

The original test case URL no longer seems to be valid, so I can only
guess what's actually happening at this point (please, reporters, attach
test cases or post them inline to avoid link rot!)

From the discussion, it sounds to me like the problem is GNU make's
built-in rule to link a binary from a single .o file, together with
Automake's .cxx.o suffix rule, so you end up with the implicit rule
chain

  foo.cxx -> foo.o -> foo

Moreover, because some source file presumably #includes foo, Automake's
automatic dependency tracking (or an explicit prerequisite in the Makefile)
is causing make to try and update foo.  Make sees that foo.cxx is newer
than foo, so it carries out the rules to update foo.

Fortunately, the workaround is simple in this case.  All you need to do
is add an explicit rule for foo, and implicit rule search will not be
performed.  Just putting

  foo: ;

in Makefile.am (which says that foo has no prerequisites and can be
updated by doing nothing) should fix it right up, without relying on
any GNU-make-specific features.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Message #28 received at 12142 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: 12142 <at> debbugs.gnu.org
Subject: Re: bug#12142: automake tries to compile a program when 'foo' and
 'foo.cxx' exist (though the former is header)
Date: Mon, 31 Aug 2020 15:14:31 -0600

It seems there is nothing left unresolved here, so closing ...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.