[FFmpeg-devel] [PATCH] Enable building 64bit FFmpeg on MacOSX
Reimar Döffinger
Reimar.Doeffinger
Mon Mar 17 13:49:29 CET 2008
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.
More information about the ffmpeg-devel
mailing list