[FFmpeg-devel] Build problem (on Os X)
Wed Feb 11 18:13:03 CET 2009
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>
>>>>> 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.
>>>>> make the added section .rodata/.text lines conditional with
>>>>> __OUTPUT_FORMAT__,macho64", that avoids the warnings and allows
>>>>> 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.
>> +SECTION .rodata align=16
>> The section uses the previous alignment argument, yasm spits a
>> 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
>> of doing that while allowing cross-compilation except by adding a
>> that parses the mach-o object file (ugh-ly!).
>> I suppose if someone is cross-compiling for Mac OS X, they should
>> 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
>> - %else
>> - SECTION .rodata align=16
>> + SECTION .rodata align=16
> What about this?
Re: an earlier suggestion for using .data: IIRC, Art tried .data and
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
foo: db 'blah'
SECTION .rodata align=16
bar: db 'bleh'
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"
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
(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.
More information about the ffmpeg-devel