[FFmpeg-devel] [PATCH] Enable building 64bit FFmpeg on MacOSX
Wed Mar 19 10:58:35 CET 2008
Diego Biurrun wrote:
> On Mon, Mar 17, 2008 at 01:49:29PM +0100, Reimar D?ffinger wrote:
>> On Mon, Mar 17, 2008 at 12:25:08PM -0000, M?ns Rullg?rd wrote:
>> > > 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.
>> I agree, but since we have no good tests, I think 1,3 and 4 can be done
>> with my suggestion I think.
> What's it going to be, guys?
In case you hadn't noticed, I'm working on getting rid of some of the
#ifdefs entirely. I wasn't aware that this was an urgent problem.
Feel free to help me with those hardcoded offsets in inline asm. GCC
is being most unfriendly.
mans at mansr.com
More information about the ffmpeg-devel