[FFmpeg-devel] Build problem (on Os X)

[David DeHaven]

On Feb 11, 2009, at 8:14 AM, Diego Biurrun wrote:

> On Wed, Feb 04, 2009 at 12:08:23PM -0800, David DeHaven wrote:
>>
>> On Feb 4, 2009, at 11:34 AM, David Conrad wrote:
>>> On Feb 4, 2009, at 2:04 PM, Art Clarke wrote:
>>>> On Wed, Feb 4, 2009 at 10:47 AM, David DeHaven <dave at sagetv.com>  
>>>> wrote:
>>>>> Putting dispatch_tabxxx in .rodata seems to skirt the issue, but
>>>>> generates heaps of warnings on 32 bit. No idea if that works on 64
>>>>> bit as I don't have access to a 64 bit machine at the moment.  
>>>>> Maybe
>>>>> make the added section .rodata/.text lines conditional with  
>>>>> "%ifidn
>>>>> __OUTPUT_FORMAT__,macho64", that avoids the warnings and allows  
>>>>> the
>>>>> system to cache the dylib code on 32 bit. Someone with more x86
>>>>> assembly experience could probably find a better solution... I'm
>>>>> just kinda hacking in the dark here. I was able to build 64 bit
>>>>> dylibs though.
>>>>
>>>> yeah; me too.
>>>
>>> <fft-rodata.diff>
>>
>> +SECTION .rodata align=16
>>
>> The section uses the previous alignment argument, yasm spits a  
>> warning
>> out for me.
>>
>> I also made the following change to x86inc.asm, but it assumes yasm
>> isn't broken. Ideally configure needs to be modified to check if yasm
>> aligns sections properly or not, but I haven't figured out a clean  
>> way
>> of doing that while allowing cross-compilation except by adding a  
>> tool
>> that parses the mach-o object file (ugh-ly!).
>>
>> I suppose if someone is cross-compiling for Mac OS X, they should  
>> have
>> otool or an appropriate objdump available...
>>
>> --- libavcodec/x86/x86inc.asm	(revision 16966)
>> +++ libavcodec/x86/x86inc.asm	(working copy)
>> @@ -29,14 +29,10 @@
>> ; Kludge: Something on OS X fails to align .rodata even given an  
>> align attribute,
>> ; so use a different read-only section.
>> %macro SECTION_RODATA 0
>> -    %ifidn __OUTPUT_FORMAT__,macho64
>> -        SECTION .text align=16
>> -    %elifidn __OUTPUT_FORMAT__,macho
>> -        SECTION .text align=16
>> +    %ifidn __OUTPUT_FORMAT__,macho
>>         fakegot:
>> -    %else
>> -        SECTION .rodata align=16
>>     %endif
>> +    SECTION .rodata align=16
>> %endmacro
>
> What about this?
>
> Diego


Re: an earlier suggestion for using .data: IIRC, Art tried .data and  
it crashed.


IMHO, the above patch and moving the table up so it's under  
SECTION_RODATA is a far more appropriate solution. Unfortunately I  
haven't had the time to work up a test to drop into configure to  
verify that section .rodata alignment works in yasm yet.

It can be done by assembling something like:
cat << EOF > blah.asm
SECTION .text
foo: db 'blah'
SECTION .rodata align=16
bar: db 'bleh'
EOF
yasm -f macho blah.asm

The rodata section should end up at virtual address 16 (or some  
multiple thereof) in the object file which can be checked with either  
otool or objdump:

otool -l blah.o | grep -A4 "segname __DATA"
    segname __DATA
       addr 0x00000010
       size 0x00000004
     offset 248
      align 2^4 (16)

i686-apple-darwin9-objdump -h blah.o | grep 'LC_SEGMENT.__DATA.__const'
   2 LC_SEGMENT.__DATA.__const 00000004  00000010  00000010  000000f8   
2**4
(second value is virtual address)

So ultimately the problem becomes having to decide which tool can be  
used to check and then parsing the output of that tool... if cross- 
compiling for Mac, then it's most likely objdump since it's installed  
with binutils, but Apple does not ship objdump with XCode, just otool  
(I built it separately).

In either case a regex pattern or two could extract the section  
address pretty easily. I think the easiest method would be to check if  
the last character is zero, if it's not then the section is not  
aligned properly. The section alignment value should also be verified  
("2^4 (16)" from otool, "2**4" in objdump).

Not a huge problem but it's time consuming work, a luxury I don't have  
at the moment.

-DrD-