Hi David, The problem is that we now have lost autoconf backwards compatibility. Using AC_PROG_OBJCXX unconditionally breaks builds on older systems that don't know about that macro. Those older systems are used by projects to build conservative (old libc) science apps. At the same time up-to-date systems require that macro, so omitting it doesn't work either.
The solution would be to conditionally include this macro on systems where it's supported. I did this on the OS-level in trunk@25794 but we need to do this based on the macro's own availability. Since AC_PROG_OBJCXX got introduced with 2.65 we could potentially use this fact in a conditional via: m4_version_compare(m4_defn([AC_AUTOCONF_VERSION]), [2.65])) Another (ugly) approach would be to add this above AC_PROG_OBJCXX: m4_pattern_allow(AC_PROG_OBJCXX) Cheers, Oliver On 7/2/12 19:32 , David Anderson wrote: > I'm told this doesn't happen with more recent versions > of the GNU tools (autoconf etc.) > -- David > > On 02-Jul-2012 6:51 AM, Eric Myers wrote: >> >> The problem seems to have been fixed for a few days, but >> has returned with the exact same error message: >> >> configure.ac:40: error: possibly undefined macro: AC_PROG_OBJCXX >> If this token and others are legitimate, please use m4_pattern_allow. >> See the Autoconf documentation. >> autoreconf: /usr/bin/autoconf failed with exit status: 1 >> >> Perhaps a later checkin overwrote the fix? >> >> -Eric >> >> > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
