[MPlayer-dev-eng] [PATCH] Fix MPlayer to compile on Darwin/x86_64

[Guillaume POIRIER]

Hello,

On Sun, Jun 7, 2009 at 2:27 AM, Diego Biurrun <diego at biurrun.de> wrote:

> On Sun, Jun 07, 2009 at 12:34:50AM +0200, Guillaume POIRIER wrote:
> >
> > On Sat, Jun 6, 2009 at 5:59 PM, Diego Biurrun <diego at biurrun.de> wrote:
> >
> > > On Sat, Jun 06, 2009 at 02:57:33PM +0200, Guillaume POIRIER wrote:
> > > >
> > > > --- mangle.h  (revision 29344)
> > > > +++ mangle.h  (working copy)
> > > > @@ -31,6 +31,14 @@
> > > >
> > > > +/* Use rip-relative addressing if compiling PIC code (or code for
> > > Darwin)
> > > > + on x86-64. */
> > > > +#if ARCH_X86_64 && (defined(PIC) || defined(__APPLE__))
> > > > +#    define LOCAL_MANGLE(a) #a "(%%rip)"
> > > > +#else
> > > > +#    define LOCAL_MANGLE(a) #a
> > > > +#endif
> > >
> > > I wonder why you need to check for __APPLE__,
> >
> > I need it because I need to detect that this file is compiled on a Darwin
> > OS, and __APPLE__ define is a define that is provided by the compiler.
> >
> > > but libavutil/internal.h does not need it...
> >
> > Why do you say that? I need the same change there too:
>
> Rejected for both MPlayer and FFmpeg.  I got rid of the last __APPLE__
> occurrences in FFmpeg, I will not allow new ones to be added.
>
> Find a way to check for this properly and portably in configure.
>


Ah Ok, now I see what you meant by "You will have to come up with a
configure test for this.  Under no circumstances can we allow a __APPLE__
check in there."
in an earlier message to this thread.I thought that __APPLE__ was OK since a
quick grep reveled many occurrences of it in MPlayer's source tree.
Adding a configure check is no biggie, so I'll add one, sure!

Guillaume

-- 
Only a very small fraction of our DNA does anything; the rest is all
comments and ifdefs.

Dan Quayle <http://www.brainyquote.com/quotes/authors/d/dan_quayle.html>  -
"This President is going to lead us out of this recovery."