PTLib/OPAL 2.18.8/3.18.8 release bundle on Linux arm.
In make/autoconf.mak, the following targets are defined as:
ifeq ($(AUTOCONF_AVAILABLE),yes)
$(CONFIGURE): $(CONFIGURE).ac $(M4_FILES) $(ACLOCAL_M4)
$(AUTOCONF)
$(ACLOCAL_M4):
cd $(dir $@) && $(ACLOCAL)
else # autoconf
$(CONFIGURE): $(CONFIGURE).ac
@echo ...
...
endif # autoconf good
As it can be seen from autoconf.mak, when Autoconf 2.71+ and Aclocal 1.15+ are detected on the host system, AUTOCONF_AVAILABLE becomes 'yes', and $(CONFIGURE) target begins to depend on $(ACLOCAL_M4). Since there's no ACLOCAL_M4 (which is actually aclocal.m4 file) in the source distribution, make executes aclocal/autoconf/configure successively.
This behaviour prevents from integrating PTLib/OPAL seamlessly into Linux system build tools, like Buildroot. Their core design is to execute each package build step in a certain order, passing a proper environment and command line options to 'configure', 'make' and 'make install'. For sure, they can do autoreconf as a pre-configuration step if needed, but they don't expect a makefile to initiate package reconfiguration at the build step. In this autoconf.mak, 'configure' command is hardcoded as:
$(CONFIGURE) $(HOST_CONFIG_PARAM) $(CONFIG_PARMS)
It doesn't pass a number of important environment variables, like paths to cross-binutils, to the configure script. So the package gets configured incorrectly.
Moreover, target 'build_top_level' does not depend on anything, while it must have $(CONFIG_FILE_PATHS) target as a prerequisite at least. This allows make to build these targets simultaneously. Well, it's easy to reproduce: run a multi-threaded make as 'make -j5'. Its stdout with interleaving configuration and source compilation messages looks really amazing.
Suggested solution:
If Autoconf 2.71+ and Aclocal 1.15+ are detected, and no aclocal.m4 is found, don't try to autoreconf automatically. Instead, issue a message requiring the user to execute aclocal/autoconf/configure first, and then stop processing the makefile.