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

[İsmail Dönmez]

Hi,

On Wed, Mar 19, 2008 at 11:37 AM, Diego Biurrun <diego at biurrun.de> 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?

Attached patch passes make codectest with 32/64bit builds, should be
good to go until a better solution is found.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: intptr_t.patch
Type: application/octet-stream
Size: 800 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080319/3d3d741d/attachment.obj>