Hi David, Finally...
diff --git a/configure.ac b/configure.ac index 6557b99..c37542e 100644 --- a/configure.ac +++ b/configure.ac @@ -37,7 +37,11 @@ fi dnl Checks for programs. AC_PROG_CC AC_PROG_CXX -AC_PROG_OBJCXX +dnl ------ +dnl Workaround for autoconf >= 2.65 backwards incompatibility +m4_pattern_allow([AC_PROG_OBJCXX]) +m4_ifdef([AC_PROG_OBJCXX],[AC_PROG_OBJCXX],) +dnl ------ AC_PROG_F77 AC_PROG_CPP AC_PROG_MAKE_SET On 7/13/12 20:58 , David Anderson wrote: > Oliver: > Where do these changes go? > Please send a diff. > -- David > > On 13-Jul-2012 9:47 AM, Oliver Bock wrote: >> 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.
