[FFmpeg-cvslog] r10187 - trunk/configure

[Måns Rullgård]

David Conrad <umovimus at gmail.com> writes:

> On Aug 25, 2007, at 7:03 PM, M?ns Rullg?rd wrote:
>
>> David Conrad <umovimus at gmail.com> writes:
>>
>>> On Aug 25, 2007, at 4:40 PM, Guillaume POIRIER wrote:
>>>
>>>> Hi,
>>>>
>>>> On 8/22/07, mru <subversion at mplayerhq.hu> wrote:
>>>>> Author: mru
>>>>> Date: Wed Aug 22 22:42:25 2007
>>>>> New Revision: 10187
>>>>>
>>>>> Log:
>>>>> fix endian check when cross-compiling
>>>>
>>>> This commit broke PPC target. You reproduce the bug quite simply by
>>>> trying to play a H264 file with ffplay:
>>>>
>>>> ./ffplay_g ~/Movies/CityLights.avi
>>>> [h264 @ 0x361788]top block unavailable for requested intra mode at
>>>> 13 0
>>
>> [...]
>>
>>>> I have no idea what the correct fix for this is though :(
>>>
>>> It seems that the strings on Mac OS X doesn't find the BIGE in the
>>> object file unless you use - as in the attached patch. Don't know if
>>> it's correct to do on other platforms though.
>>>
>>>
>>> diff --git a/configure b/configure
>>> index a9a4fd7..a6906b1 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -1522,7 +1522,7 @@ EOF
>>>  check_cc <<EOF || die "endian test failed"
>>>  unsigned int endian = 'B' << 24 | 'I' << 16 | 'G' << 8 | 'E';
>>>  EOF
>>> -strings $TMPO | grep -q BIGE && enable bigendian
>>> +strings - $TMPO | grep -q BIGE && enable bigendian
>>>
>>>  # ---
>>>  # check availability of some header files
>>
>> That should be safe on any conforming platform.  I don't understand
>> how this could make a difference though.  Can someone please explain
>> what's going on?  What is special about strings on macos?
>
> It seems that strings on Mac OS X doesn't recognize a string if it's  
> the minimum string length (default of 4) and ends on a section end  
> without a newline/null within the section. The test case is being  
> compiled so that the data section is 4 bytes long, containing only  
> the BIGE string. Since - ignores Mach-O sections, the string is found  
> without a problem because the next byte outside the section is 0.  
> Using a longer string also works, as does ensuring that there's a  
> null byte in the data section.

Thanks, that explains it, even if it makes no sense that should be
like that.  Oh well, it should be fixed now.

-- 
M?ns Rullg?rd
mans at mansr.com