[FFmpeg-devel] [PATCH] Enable building 64bit FFmpeg on MacOSX

[Måns Rullgård]

Reimar D?ffinger wrote:
> On Mon, Mar 17, 2008 at 12:52:58PM +0200, ?smail D?nmez wrote:
>> On Mon, Mar 17, 2008 at 12:34 PM, M?ns Rullg?rd <mans at mansr.com> wrote:
>> >
>> >  Diego Biurrun wrote:
>> >  > On Mon, Mar 17, 2008 at 11:28:30AM +0200, ?smail D?nmez wrote:
>> >  >>
>> >  >> On Mon, Mar 17, 2008 at 11:25 AM, Diego Biurrun <diego at biurrun.de> wrote:
>> >  >> > On Sat, Mar 15, 2008 at 05:03:22PM +0200, ?smail D?nmez wrote:
>> >  >> >  > To workaround this attached patch checks if CFLAGS contains -m64 and
>> >  >> >  > then sets 64bit flags. This is similar to already existing -m32 check
>> >  >> >  > in configure.
>> >  >> >
>> >  >> >  I'd rather have you find a proper solution, this is quite ugly...
>> >  >>
>> >  >> Suggestions welcome.
>> >  >
>> >  > Mans?
>> >  >
>> >  > I have no better solutions available, so I'll apply your patch if you
>> >  > update it to match HEAD again.  Unless somebody has better ideas...
>> >
>> >  The correct way would be to try compiling something that will fail on
>> >  one arch or the other.  It's a trivial bit of assembler (use %rax or so),
>> >  but there is plain C code using the HAVE_FAST_64BIT flag, which would
>> >  get the wrong value if inline asm is not supported.  Another possibility
>> >  might be to check the size of long and/or pointer types (using nm).
>>
>> How does the attached patch look?
>
> Seems ugly to me, maybe better check compilation of something like
>
> int test[sizeof(intptr_t) - 7];

That's much better, but I'm not entirely comfortable with any of this.
The problem is, there are several distinct aspects to the 32/64-bit
distinction:

1. Whether to require PIC for shared libs
The need for PIC on x86-64 is due to immediate offsets being limited to 32
bits, wherefore textrels cannot be used.  It is perfectly possible, in
theory, to restrict symbol addresses to the low 4GB of the address space,
which would obviate the need for PIC while still making use of 64-bit
features.  I don't know of any compiler/linker options that will make
this happen, but I wouldn't completely discount the possibility.
This matters only for the linker flags and for a few bits of inline
assembler that test for the PIC preprocessor symbol.  Short of trying
to link something with suitable relocations, I can't think of a reliable
test for this.

2. Register names to use in assembler code
Again, availability of the x86_64 register set is independent of the
sizes of C types.  This is easy to test for in configure.

3. Whether the machine has 64-bit words
This is an architecture-independent question.  It is entirely possible for
both long and pointers to be 32-bit, with long long being 64 bits wide,
even on a native 64-bit machine.  From a C code point of view, this
case is indistinguishable from 64-emulation by the compiler as typically
done on 32-bit machines.  I can't think of a reliable way to test this.

4. Size of various C types
Some assembler code contains hardcoded offsets into structs which depend
on the size of C types.

The existing uses of ARCH_X86_64 in the code fall into one of the above
categories.  IMO, we should try to separate the cases with individual
tests for each.  I have the feeling this would make a lot of problems
magically go away.

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