[Buildroot] autotools, autorefconf, libtoolize and non-existing m4 directory

Michael Walle michael at walle.cc
Tue Dec 10 10:34:51 UTC 2019

Hi Thomas, Hi Peter,

we have a package [1] where:
  - we have AC_CONFIG_MACRO_DIR([m4]) in configure.ac
  - we have ACLOCAL_AMFLAGS = -I m4 in Makefile.am
  - we do *not* have an m4/ subdirectory (there is actually a commit
    that introduces an empty m4/ directory, but that should not be

We now do trigger a bug where autoreconf from the host works perfectly
and the autoreconf of busybox do not. Here is our first analysis:
  - originating from [2], there was an upstream patch which degrades the
    absence of a local m4 directory from fatal to just a warning in the
    aclocal step.
  - the current aclocal script treats just the _first_ include directory
    that way. Ie. it assumes, that the local m4/ is the first one in
    @user_includes, see [3]
  - buildroot sets the first one by its own in the automake package,
    see [4], because it supplies the first include already in the

Is this behaviour intended? There is also an install option to aclocal
which uses first directory in the list.

Unfortunately, I cannot come up with a solution other than:
and buildroot would set its own include path in SOME_OTHER_FLAGS. But
I'd guess that will break many packages. So maybe the current behaviour
is the lesser evil. But it does not really work like on the host system.


[1] https://github.com/kontron/keapi
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565663#50

More information about the buildroot mailing list