aclocal (and probably other tools) not working in shared folder

[carlos.abalde]

How to reproduce using Vagrant:

• Use a minimal Vagrantfile:

  $script = <<SCRIPT
      yum install -y epel-release
      yum install -y automake libtool
  SCRIPT
  
  Vagrant.configure('2') do |config|
      config.vm.box = 'allenta/bento.centos-7.4'
      config.vm.box_version = '=201803.24.0'
      config.vm.synced_folder '.', '/vagrant', :nfs => false
      config.vm.provision :shell, :privileged => true, :inline => $script
  end
  

• Create a minimal configure.ac file in /vagrant/ (i.e. shared folder):

  AC_INIT([helloworld], [0.1], [hello@example.com])
  AM_INIT_AUTOMAKE
  AC_PROG_CC
  AC_CONFIG_FILES([Makefile])
  AC_OUTPUT
  

• Try to run aclocal:

  $ cd /vagrant
  
  $ aclocal
  /usr/bin/m4:/tmp/am4tHcrP6s/traces.m4:320: ERROR: end of file in string
  Use of uninitialized value $msg in concatenation (.) or string at /usr/bin/autom4te line 1026.
  Use of uninitialized value $stacktrace in pattern match (m//) at /usr/bin/autom4te line 1026.
  unknown channel X])])])dnl
  ])
  igure.ac:1: -1- m4_pattern_allow(^mandir$)
   at /usr/share/autoconf/Autom4te/Channels.pm line 638.
      Autom4te::Channels::msg('X])])])dnl\x{a}])\x{a}igure.ac:1: -1- m4_pattern_allow(^mandir$)\x{a}', undef, 'warning: ', 'partial', 0) called at /usr/bin/autom4te line 1026
  aclocal: error: echo failed with exit status: 1
  

• Try same thing moving /vagrant/configure.ac to a different non-shared location (e.g. /tmp). The command will work as expected (i.e. not output and some files generated).

This has been tested in the following combinations. It only worked when using Ubuntu 19.10:

• macOS Catalina 10.15.2 + VirtualBox 6.0.16 + Vagrant 2.2.6
• macOS Catalina 10.15.2 + VirtualBox 6.1.2 + Vagrant 2.2.6 + ​https://github.com/oracle/vagrant-boxes/issues/178#issuecomment-575936662
• Ubuntu 18.04 + VirtualBox 6.0.14 + Vagrant 2.2.6
• Ubuntu 18.04 + VirtualBox 6.1.2 + Vagrant 2.2.6 + ​https://github.com/oracle/vagrant-boxes/issues/178#issuecomment-575936662
• Ubuntu 19.10 + VirtualBox 6.1.0 + Vagrant 2.2.6 + ​https://github.com/oracle/vagrant-boxes/issues/178#issuecomment-575936662

In the past this worked fine.

[Frank Batschulat (Oracle)]

Would you please explain what the "error" message:

igure.ac:1: -1- m4_pattern_allow(^mandir$)
 at /usr/share/autoconf/Autom4te/Channels.pm line 638.
    Autom4te::Channels::msg('X])])])dnl\x{a}])\x{a}igure.ac:1: -1- m4_pattern_allow(^mandir$)\x{a}', undef, 'warning: ', 'partial', 0) called at /usr/bin/autom4te line 1026
aclocal: error: echo failed with exit status: 1

Also for your test scenario, would ypu please clearly explain what is being run in the guest and what is being run on the host?

Is trying to tell us? What exactly whent wrong? What operation/action failed?

That might help speeding up looking into this report quite a bit.

[carlos.abalde]

I've not idea, but I don't think understanding that would help at all here (and autotool messages are usually not friendly at all). The point is using a minimal configure.ac file like the one in the example, the aclocal should complete execution silently. Unsuccessfully tried to use strace to understand what's going on.

[carlos.abalde]

About the host / guest question: the guest is in all cases CentOS 7.4.

[Frank Batschulat (Oracle)]

If you think that error is irrelevant, then please describe exactly what fails, how it failes when and where it fails.

aclocal (and probably other tools) not working in shared folder

Is not a legitimate failure description, it's very close to "my computer is not working". You say:

The command will work as expected (i.e. not output and some files generated). 

That implies, in the failure case, the error message is spit out and as such this error message and what it is complaining about is indeed very much of interest in understanding the problem and root causing the issue.

Also, I have not asked for the Linux version yet, I did ask, which of the steps you put together in the description are to be executed on the host and which on the guest. Also you have neglected any information about the shared folder configuration.

[carlos.abalde]

Sorry, but:

• I've provided a Vagrantfile and Linux image (linked in the Vagrantfile) that trivially allows to reproduce this at least in macOS Catalina 10.15.2 and Ubuntu 18.04. That's not exactly "my computer is not working".

• Sadly the error message is not helpful here, but executions using a normal folder and a shared folder are behaving differently: one works and the other on doesn't. I think that's helpful information.

• I assumed it was obvious but all steps are executed in the guest.

In any case, if you think that's not enough information, please go ahead and close the issue.

Thanks!

[Frank Batschulat (Oracle)]

Replying to carlos.abalde:

• I've provided a Vagrantfile and Linux image (linked in the Vagrantfile) that trivially allows to reproduce this at least in macOS Catalina 10.15.2 and Ubuntu 18.04. That's not exactly "my computer is not working".
• Sadly the error message is not helpful here, but executions using a normal folder and a shared folder are behaving differently: one works and the other on doesn't. I think that's helpful information.

In order to establish a base line between working and broken we'd need as much information about the failure case and how it manifests itself as possible. If you cannot even tell what underlaying cause of the error message is, how can you tell it is irrelevant? That's what I was trying to get out here.

• I assumed it was obvious but all steps are executed in the guest.

No, this is not obvious, this is not a Vagrant support channel, this is the Virtualbox bug tracking system.

Having said all that, I hoped we can get some immediate hints as to what is causing the hickup, thats apparently not possible so we must first try out to reproduce this using the steps provided so far.

[carlos.abalde]

I suggested the error was irrelevant based on my personal experience with autotools, but yeah, you're right.

I forgot to mention the Vagrant vbguest plugin is installed in order to upgrade guest additions during the initial boot of the VM.

I'll update this if I can provide additional details. I suspect this could be related with the upgrade of the guest additions, but I still need to do some extra tests in order to fully check my current hyppotesis.

[carlos.abalde]

I found behavior is different when using different guest additions:

• When using installed guest additions (5.1.16) everything works fine.

• When using upgraded guest additions (using the vbguest plugin) the issue shows up.

I don't know if this is a VirtualBox bug, a vbguest guest bug or even a Vagrant bug. I you think is worth investigating it, please let me know and I will provide any additional info the might be needed.

Thank you!

[carlos.abalde]

Lot's of testing later, I can fully confirm (1) this definitely is a guest additions thing (old versions work fine, but when updating to the right version matching VirtualBox the issue shows up); and (2) it seems this is only happening when using CentOS 7 as guest (tested with several CentOS images; not happening in Ubuntu Xenial and Bionic).

[carlos.abalde]

Next I include a recap with current status and hopefully a better description in order to allow anybody interested easily reproduce the issue.

As I said, it seems this is an issue related with Guest Additions when using CentOS 7 as guest. I've been able to reproduce it using macOS Catalina 10.15.2, Ubuntu 18.04 and Ubuntu 19.10 as host (yes, Ubuntu 19.10 too; that was a mistake in the initial bug report). If using a guest with old Guest Additions everything works as expected, but once they are updated to match the VirtualBox version the issue shows up. This has been tested with VirtualBox 6.0.14, 6.0.16, 6.1.0 and 6.1.2.

In order to reproduce this you need the following software installed in the host:

• VirtualBox 6.0.x or 6.1.x.
• Vagrant 2.2.6. If using VirtualBox 6.1.x you'll to follow instructions in ​https://github.com/oracle/vagrant-boxes/issues/178#issuecomment-575936662 in order to workaround a minor issue to be fixed in the next Vagrant release.
• Vagrant vbguest plugin 0.23.0 (i.e. vagrant plugin install vagrant-vbguest). This plugin checks Guest Additions when booting the VM and updates them on demand.

Steps to reproduce:

• Use a minimal Vagrantfile:

  $script = <<SCRIPT
      yum install -y epel-release
      yum install -y automake libtool
  SCRIPT
  
  Vagrant.configure('2') do |config|
      config.vm.box = 'allenta/bento.centos-7.4'
      config.vm.box_version = '=201803.24.0'
      config.vm.synced_folder '.', '/vagrant', type: 'virtualbox'
      config.vm.provision :shell, :privileged => true, :inline => $script
      config.vbguest.auto_update = true
  end
  

• Bootstrap the VM. Please beware Guest Additions will be upgraded during the initial bootstrap and you'll need to run a manual reload (i.e. vagrant reload) in order to let the VM mount the shared folder:

  $ vagrant up
  
  $ vagrant reload
  
  $ vagrant ssh
  

• Connect to the VM (i.e. vagrant ssh) and create a minimal configure.ac file in /vagrant/ (i.e. shared folder):

  AC_INIT([helloworld], [0.1], [hello@example.com])
  AM_INIT_AUTOMAKE
  AC_PROG_CC
  AC_CONFIG_FILES([Makefile])
  AC_OUTPUT
  

• Still connected to the VM, try to run aclocal:

  $ cd /vagrant
  
  $ aclocal
  <... error message ...>
  

If you try same thing moving /vagrant/configure.ac to a different non-shared location (e.g. /tmp) the command will work as expected (i.e. not output and some files generated).

Additionally, if you destroy the VM (i.e. vagrant destroy) and adjust the Vagrantfile to prevent upgrade of the Guest Addtions (i.e. set config.vbguest.auto_update to false), aclocal will work as expected in the shared folder.

Also, you can try using alternative CentOS 7 images to get the same result. I've tried with the following ones:

config.vm.box = 'bento/centos-7.4'
config.vm.box_version = '=201803.24.0'

config.vm.box = 'centos/7'
config.vm.box_version = '=1905.1'

It seems this is only happening when using CentOS 7 as guest (tested with several CentOS images; not happening in Ubuntu Xenial and Bionic).

[carlos.abalde]

We've been digging on this and now we know the problem is not the location of the configure.ac file. The problem is the working directory when running aclocal.

When aclocal is executed it forks several processes that create temporary files in the autom4te.cache folder. When the working directory is a VirtualBox shared folder some of those files are truncated and that breaks the whole thing.

We've been able to reduce the test case to the following command (i.e. the configure.ac file is not needed anymore to reproduce this):

$ cd /vagrant

$ rm -rf autom4te.cache

$ autom4te --language Autoconf-without-aclocal-m4 /usr/share/aclocal-1.13/init.m4 /usr/share/aclocal-1.13/cond.m4 /usr/share/aclocal-1.13/depend.m4 --trace='AC_DEFUN:$f::$n::${::}%'
<... error message ...>

$ less autom4te.cache/traces.0
<... truncated file ...>

Hope it helps.

[Frank Batschulat (Oracle)]

Thanks thats interesting, because if this is truly the remaining test case, it can be reduced even further and should still reproduce such an existing problem without having Vagrant in the stack at all.

In theory it should reproduce just with:

1) CentOS7 guest with installed GA and installed m4 and autoconf

packages (because /usr/bin/autom4te is part of the GNU autoconf package).

2) associate a shared folder with the guest VM and have it automounted in the guest

3) in the guest, change to the shared folder directory and run the following command:

autom4te --language Autoconf-without-aclocal-m4 /usr/share/aclocal-1.15/init.m4 /usr/share/aclocal-1.15/cond.m4 /usr/share/aclocal-1.15/depend.m4 --trace='AC_DEFUN:$f::$n::${::}%'

and get this result below if all things work:

fbatschu@minibox:~$ mkdir m4test
fbatschu@minibox:~$ cd m4test/
fbatschu@minibox:~/m4test$ autom4te --language Autoconf-without-aclocal-m4 /usr/share/aclocal-1.15/init.m4 /usr/share/aclocal-1.15/cond.m4 /usr/share/aclocal-1.15/depend.m4 --trace='AC_DEFUN:$f::$n::${::}%'
/usr/share/aclocal-1.15/init.m4::AC_DEFUN::AM_INIT_AUTOMAKE::AC_PREREQ([2.65])dnl dnl Autoconf wants to disallow AM_ names. We explicitly allow dnl the ones we care about. m4_pattern_allow([^AM_[A-Z]+FLAGS$])dnl AC_REQUIRE([AM_SET_CURRENT_AUTOMAKE_VERSION])dnl AC_REQUIRE([AC_PROG_INSTALL])dnl if test "`cd $srcdir && pwd`" != "`pwd`"; then # Use -I$(srcdir) only when $(srcdir) != ., so that make's output # is not polluted with repeated "-I." AC_SUBST([am__isrc], [' -I$(srcdir)'])_AM_SUBST_NOTMAKE([am__isrc])dnl # test to see if srcdir already configured if test -f $srcdir/config.status; then AC_MSG_ERROR([source directory already configured; run "make distclean" there first]) fi fi # test whether we have cygpath if test -z "$CYGPATH_W"; then if (cygpath --version) >/dev/null 2>/dev/null; then CYGPATH_W='cygpath -w' else CYGPATH_W=echo fi fi AC_SUBST([CYGPATH_W]) # Define the identity of the package. dnl Distinguish between old-style and new-style calls. m4_ifval([$2], [AC_DIAGNOSE([obsolete], [$0: two- and three-arguments forms are deprecated.]) m4_ifval([$3], [_AM_SET_OPTION([no-define])])dnl AC_SUBST([PACKAGE], [$1])dnl AC_SUBST([VERSION], [$2])], [_AM_SET_OPTIONS([$1])dnl dnl Diagnose old-style AC_INIT with new-style AM_AUTOMAKE_INIT. m4_if( m4_ifdef([AC_PACKAGE_NAME], [ok]):m4_ifdef([AC_PACKAGE_VERSION], [ok]), [ok:ok],, [m4_fatal([AC_INIT should be called with package and version arguments])])dnl AC_SUBST([PACKAGE], ['AC_PACKAGE_TARNAME'])dnl AC_SUBST([VERSION], ['AC_PACKAGE_VERSION'])])dnl _AM_IF_OPTION([no-define],, [AC_DEFINE_UNQUOTED([PACKAGE], ["$PACKAGE"], [Name of package]) AC_DEFINE_UNQUOTED([VERSION], ["$VERSION"], [Version number of package])])dnl # Some tools Automake needs. AC_REQUIRE([AM_SANITY_CHECK])dnl AC_REQUIRE([AC_ARG_PROGRAM])dnl AM_MISSING_PROG([ACLOCAL], [aclocal-${am__api_version}]) AM_MISSING_PROG([AUTOCONF], [autoconf]) AM_MISSING_PROG([AUTOMAKE], [automake-${am__api_version}]) AM_MISSING_PROG([AUTOHEADER], [autoheader]) AM_MISSING_PROG([MAKEINFO], [makeinfo]) AC_REQUIRE([AM_PROG_INSTALL_SH])dnl AC_REQUIRE([AM_PROG_INSTALL_STRIP])dnl AC_REQUIRE([AC_PROG_MKDIR_P])dnl # For better backward compatibility. To be removed once Automake 1.9.x # dies out for good. For more background, see: # <http://lists.gnu.org/archive/html/automake/2012-07/msg00001.html> # <http://lists.gnu.org/archive/html/automake/2012-07/msg00014.html> AC_SUBST([mkdir_p], ['$(MKDIR_P)']) # We need awk for the "check" target (and possibly the TAP driver). The # system "awk" is bad on some platforms. AC_REQUIRE([AC_PROG_AWK])dnl AC_REQUIRE([AC_PROG_MAKE_SET])dnl AC_REQUIRE([AM_SET_LEADING_DOT])dnl _AM_IF_OPTION([tar-ustar], [_AM_PROG_TAR([ustar])], [_AM_IF_OPTION([tar-pax], [_AM_PROG_TAR([pax])], [_AM_PROG_TAR([v7])])]) _AM_IF_OPTION([no-dependencies],, [AC_PROVIDE_IFELSE([AC_PROG_CC], [_AM_DEPENDENCIES([CC])], [m4_define([AC_PROG_CC], m4_defn([AC_PROG_CC])[_AM_DEPENDENCIES([CC])])])dnl AC_PROVIDE_IFELSE([AC_PROG_CXX], [_AM_DEPENDENCIES([CXX])], [m4_define([AC_PROG_CXX], m4_defn([AC_PROG_CXX])[_AM_DEPENDENCIES([CXX])])])dnl AC_PROVIDE_IFELSE([AC_PROG_OBJC], [_AM_DEPENDENCIES([OBJC])], [m4_define([AC_PROG_OBJC], m4_defn([AC_PROG_OBJC])[_AM_DEPENDENCIES([OBJC])])])dnl AC_PROVIDE_IFELSE([AC_PROG_OBJCXX], [_AM_DEPENDENCIES([OBJCXX])], [m4_define([AC_PROG_OBJCXX], m4_defn([AC_PROG_OBJCXX])[_AM_DEPENDENCIES([OBJCXX])])])dnl ]) AC_REQUIRE([AM_SILENT_RULES])dnl dnl The testsuite driver may need to know about EXEEXT, so add the dnl 'am__EXEEXT' conditional if _AM_COMPILER_EXEEXT was seen. This dnl macro is hooked onto _AC_COMPILER_EXEEXT early, see below. AC_CONFIG_COMMANDS_PRE(dnl [m4_provide_if([_AM_COMPILER_EXEEXT], [AM_CONDITIONAL([am__EXEEXT], [test -n "$EXEEXT"])])])dnl # POSIX will say in a future version that running "rm -f" with no argument # is OK; and we want to be able to make that assumption in our Makefile # recipes. So use an aggressive probe to check that the usage we want is # actually supported "in the wild" to an acceptable degree. # See automake bug#10828. # To make any issue more visible, cause the running configure to be aborted # by default if the 'rm' program in use doesn't match our expectations; the # user can still override this though. if rm -f && rm -fr && rm -rf; then : OK; else cat >&2 <<'END' Oops! Your 'rm' program seems unable to run without file operands specified on the command line, even when the '-f' option is present. This is contrary to the behaviour of most rm programs out there, and not conforming with the upcoming POSIX standard: <http://austingroupbugs.net/view.php?id=542> Please tell bug-automake@gnu.org about your system, including the value of your $PATH and any error possibly output before this message. This can help us improve future automake versions. END if test x"$ACCEPT_INFERIOR_RM_PROGRAM" = x"yes"; then echo 'Configuration will proceed anyway, since you have set the' >&2 echo 'ACCEPT_INFERIOR_RM_PROGRAM variable to "yes"' >&2 echo >&2 else cat >&2 <<'END' Aborting the configuration process, to ensure you take notice of the issue. You can download and install GNU coreutils to get an 'rm' implementation that behaves properly: <http://www.gnu.org/software/coreutils/>. If you want to complete the configuration process using your problematic 'rm' anyway, export the environment variable ACCEPT_INFERIOR_RM_PROGRAM to "yes", and re-run configure. END AC_MSG_ERROR([Your 'rm' program is bad, sorry.]) fi fi dnl The trailing newline in this macro's definition is deliberate, for dnl backward compatibility and to allow trailing 'dnl'-style comments dnl after the AM_INIT_AUTOMAKE invocation. See automake bug#16841. 
/usr/share/aclocal-1.15/init.m4::AC_DEFUN::_AC_AM_CONFIG_HEADER_HOOK::# Compute $1's index in $config_headers. _am_arg=$1 _am_stamp_count=1 for _am_header in $config_headers :; do case $_am_header in $_am_arg | $_am_arg:* ) break ;; * ) _am_stamp_count=`expr $_am_stamp_count + 1` ;; esac done echo "timestamp for $_am_arg" >`AS_DIRNAME(["$_am_arg"])`/stamp-h[]$_am_stamp_count
/usr/share/aclocal-1.15/cond.m4::AC_DEFUN::AM_CONDITIONAL::AC_PREREQ([2.52])dnl m4_if([$1], [TRUE], [AC_FATAL([$0: invalid condition: $1])], [$1], [FALSE], [AC_FATAL([$0: invalid condition: $1])])dnl AC_SUBST([$1_TRUE])dnl AC_SUBST([$1_FALSE])dnl _AM_SUBST_NOTMAKE([$1_TRUE])dnl _AM_SUBST_NOTMAKE([$1_FALSE])dnl m4_define([_AM_COND_VALUE_$1], [$2])dnl if $2; then $1_TRUE= $1_FALSE='#' else $1_TRUE='#' $1_FALSE= fi AC_CONFIG_COMMANDS_PRE( [if test -z "${$1_TRUE}" && test -z "${$1_FALSE}"; then AC_MSG_ERROR([[conditional "$1" was never defined. Usually this means the macro was only invoked conditionally.]]) fi])
/usr/share/aclocal-1.15/depend.m4::AC_DEFUN::_AM_DEPENDENCIES::AC_REQUIRE([AM_SET_DEPDIR])dnl AC_REQUIRE([AM_OUTPUT_DEPENDENCY_COMMANDS])dnl AC_REQUIRE([AM_MAKE_INCLUDE])dnl AC_REQUIRE([AM_DEP_TRACK])dnl m4_if([$1], [CC], [depcc="$CC" am_compiler_list=], [$1], [CXX], [depcc="$CXX" am_compiler_list=], [$1], [OBJC], [depcc="$OBJC" am_compiler_list='gcc3 gcc'], [$1], [OBJCXX], [depcc="$OBJCXX" am_compiler_list='gcc3 gcc'], [$1], [UPC], [depcc="$UPC" am_compiler_list=], [$1], [GCJ], [depcc="$GCJ" am_compiler_list='gcc3 gcc'], [depcc="$$1" am_compiler_list=]) AC_CACHE_CHECK([dependency style of $depcc], [am_cv_$1_dependencies_compiler_type], [if test -z "$AMDEP_TRUE" && test -f "$am_depcomp"; then # We make a subdir and do the tests there. Otherwise we can end up # making bogus files that we don't know about and never remove. For # instance it was reported that on HP-UX the gcc test will end up # making a dummy file named 'D' -- because '-MD' means "put the output # in D". rm -rf conftest.dir mkdir conftest.dir # Copy depcomp to subdir because otherwise we won't find it if we're # using a relative directory. cp "$am_depcomp" conftest.dir cd conftest.dir # We will build objects and dependencies in a subdirectory because # it helps to detect inapplicable dependency modes. For instance # both Tru64's cc and ICC support -MD to output dependencies as a # side effect of compilation, but ICC will put the dependencies in # the current directory while Tru64 will put them in the object # directory. mkdir sub am_cv_$1_dependencies_compiler_type=none if test "$am_compiler_list" = ""; then am_compiler_list=`sed -n ['s/^#*\([a-zA-Z0-9]*\))$/\1/p'] < ./depcomp` fi am__universal=false m4_case([$1], [CC], [case " $depcc " in #( *\ -arch\ *\ -arch\ *) am__universal=true ;; esac], [CXX], [case " $depcc " in #( *\ -arch\ *\ -arch\ *) am__universal=true ;; esac]) for depmode in $am_compiler_list; do # Setup a source with many dependencies, because some compilers # like to wrap large dependency lists on column 80 (with \), and # we should not choose a depcomp mode which is confused by this. # # We need to recreate these files for each test, as the compiler may # overwrite some of them when testing with obscure command lines. # This happens at least with the AIX C compiler. : > sub/conftest.c for i in 1 2 3 4 5 6; do echo '#include "conftst'$i'.h"' >> sub/conftest.c # Using ": > sub/conftst$i.h" creates only sub/conftst1.h with # Solaris 10 /bin/sh. echo '/* dummy */' > sub/conftst$i.h done echo "${am__include} ${am__quote}sub/conftest.Po${am__quote}" > confmf # We check with '-c' and '-o' for the sake of the "dashmstdout" # mode. It turns out that the SunPro C++ compiler does not properly # handle '-M -o', and we need to detect this. Also, some Intel # versions had trouble with output in subdirs. am__obj=sub/conftest.${OBJEXT-o} am__minus_obj="-o $am__obj" case $depmode in gcc) # This depmode causes a compiler race in universal mode. test "$am__universal" = false || continue ;; nosideeffect) # After this tag, mechanisms are not by side-effect, so they'll # only be used when explicitly requested. if test "x$enable_dependency_tracking" = xyes; then continue else break fi ;; msvc7 | msvc7msys | msvisualcpp | msvcmsys) # This compiler won't grok '-c -o', but also, the minuso test has # not run yet. These depmodes are late enough in the game, and # so weak that their functioning should not be impacted. am__obj=conftest.${OBJEXT-o} am__minus_obj= ;; none) break ;; esac if depmode=$depmode source=sub/conftest.c object=$am__obj depfile=sub/conftest.Po tmpdepfile=sub/conftest.TPo $SHELL ./depcomp $depcc -c $am__minus_obj sub/conftest.c >/dev/null 2>conftest.err && grep sub/conftst1.h sub/conftest.Po > /dev/null 2>&1 && grep sub/conftst6.h sub/conftest.Po > /dev/null 2>&1 && grep $am__obj sub/conftest.Po > /dev/null 2>&1 && ${MAKE-make} -s -f confmf > /dev/null 2>&1; then # icc doesn't choke on unknown options, it will just issue warnings # or remarks (even with -Werror). So we grep stderr for any message # that says an option was ignored or not supported. # When given -MP, icc 7.0 and 7.1 complain thusly: # icc: Command line warning: ignoring option '-M'; no argument required # The diagnosis changed in icc 8.0: # icc: Command line remark: option '-MP' not supported if (grep 'ignoring option' conftest.err || grep 'not supported' conftest.err) >/dev/null 2>&1; then :; else am_cv_$1_dependencies_compiler_type=$depmode break fi fi done cd .. rm -rf conftest.dir else am_cv_$1_dependencies_compiler_type=none fi ]) AC_SUBST([$1DEPMODE], [depmode=$am_cv_$1_dependencies_compiler_type]) AM_CONDITIONAL([am__fastdep$1], [ test "x$enable_dependency_tracking" != xno && test "$am_cv_$1_dependencies_compiler_type" = gcc3]) 
/usr/share/aclocal-1.15/depend.m4::AC_DEFUN::AM_SET_DEPDIR::AC_REQUIRE([AM_SET_LEADING_DOT])dnl AC_SUBST([DEPDIR], ["${am__leading_dot}deps"])dnl 
/usr/share/aclocal-1.15/depend.m4::AC_DEFUN::AM_DEP_TRACK::AC_ARG_ENABLE([dependency-tracking], [dnl AS_HELP_STRING( [--enable-dependency-tracking], [do not reject slow dependency extractors]) AS_HELP_STRING( [--disable-dependency-tracking], [speeds up one-time build])]) if test "x$enable_dependency_tracking" != xno; then am_depcomp="$ac_aux_dir/depcomp" AMDEPBACKSLASH='\' am__nodep='_no' fi AM_CONDITIONAL([AMDEP], [test "x$enable_dependency_tracking" != xno]) AC_SUBST([AMDEPBACKSLASH])dnl _AM_SUBST_NOTMAKE([AMDEPBACKSLASH])dnl AC_SUBST([am__nodep])dnl _AM_SUBST_NOTMAKE([am__nodep])dnl 
fbatschu@minibox:~/m4test$ ls
autom4te.cache

fbatschu@minibox:~/m4test$ ls -la autom4te.cache/traces.0
-rw-r--r-- 1 fbatschu staff 13052 Jan 22 13:50 autom4te.cache/traces.0

That way we can get Vagrant out of the way.

[davidfb]

Indeed, we've tried to directly load with Virtualbox a CentOS machine from Vagrant's locally stored base boxes, to sort of taking Vagrant off the equation. We've installed guest additions and the packages you've suggested and we configured a shared folder to be automounted as well. When executing autom4te from the shared folder it failed, whereas it succeeded when executed from any other folder, so we think Vagrant has nothing to do with this and any further debugging can be done without it.

[Frank Batschulat (Oracle)]

Replying to davidfb:

Indeed, we've tried to directly load with Virtualbox a CentOS machine from Vagrant's locally stored base boxes, to sort of taking Vagrant off the equation. We've installed guest additions and the packages you've suggested and we configured a shared folder to be automounted as well. When executing autom4te from the shared folder it failed, whereas it succeeded when executed from any other folder, so we think Vagrant has nothing to do with this and any further debugging can be done without it.

Thanks for the update with this interesting development, this is actually right where I wanted this to be when I started to raise my all questions, slowly directing the whole thing to this minimal reproducable scenario without Vagrant.

[carlos.abalde]

Any news about this? Have you been able to reproduce it? Thanks!