Re: Further GUB failure

[David Kastrup]

"Phil Holmes" <address@hidden> writes:

> ----- Original Message ----- 
> From: "David Kastrup" <address@hidden>
> To: "Phil Holmes" <address@hidden>
> Cc: <address@hidden>
> Sent: Sunday, August 23, 2015 4:00 PM
> Subject: Re: Further GUB failure
>
>
>> Phil Holmes <address@hidden> writes:
>>
>>> I'm now getting this error:
>>>
>>> /home/gub/NewGub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--
>>> lilypond.git-release-unstable/flower/offset.cc:43:25: error:
>>> 'isinf' was not
>>> declared in this scope
>>>    if (!isinf (z2[Y_AXIS]))
>>>                          ^
>>>
>>> It looks like the compiler cannot find isinf, and possibly this
>>> patch is guilty:
>>>
>>> http://code.google.com/p/lilypond/issues/detail?id=4550
>>
>> isinf is supposed to be defined in cmath (without scoping) which is
>> included by flower/include/offset.hh.  And of course this works on most
>> platforms or we'd have gotten complaints already.
>>
>> Now darwin-ppc is an obsolete platform and consequently our cross
>> compiler/library is likely not all that up-to-date.  I fear this is
>> likely a compiler/library bug and it will likely be rather tough to
>> figure out an appropriate workaround when the only available test is
>> running GUB by a volunteer without much knowledge about either GUB's
>> internal workings or Darwin-PPC.
>>
>> Would it be feasible to run on a version where the patch for issue 4550
>> has been reverted?  We might cheat our way through in that manner (this
>> is not likely to have runtime effects) but short of a volunteer to
>> figure out what's going wrong here in detail, it might mean that maybe
>> it's time to retire Darwin-PPC.  We can still bring it back in once
>> somebody volunteers to fix this and possibly future problems.
>>
>> -- 
>> David Kastrup
>
>
> I applied Hosoda-San's patch and the problem moved to lookup.cc.
> Fixed that and got a fail with another *.cc.  It would seem the best
> fix would be for someone with the skills in Unix command line to
> replace all instances of isinf and isnan (any others?) with the
> std::isnan prefix?
>
> It only takes a couple of minutes for the build to fail, so
> experimenting to get rid of the bug is not too wearisome.

Dan, wasn't the idea of the patch to remove "using std" from the
_include_ files where they'd mess with the namespace of arbitrary files
including them?  Wouldn't that mean that a good fix not defeating the
original purpose of the patch would be to just put the respective using
statement in the .cc files?

What's your preferred fix?

-- 
David Kastrup