Hi,

On 7/13/12 20:58 , David Anderson wrote:
> Where do these changes go?
> Please send a diff.

Since I'm not autohell expert I just proposed a method, not an actual
fix so far. I'm looking into the conditional solution but if anyone can
do it quicker, please step forward.

The ugly brute force fix would just be what I wrote, add this above
AC_PROG_OBJCXX (in configure.ac):

m4_pattern_allow(AC_PROG_OBJCXX)


Oliver

> 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.

Reply via email to