[FFmpeg-devel] [PATCH] remove useless math.h include in libavutil/mathematics.h

[David Conrad]

On Aug 25, 2008, at 12:07 PM, M?ns Rullg?rd wrote:

> Reimar D?ffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> writes:
>
>> On Mon, Aug 25, 2008 at 05:47:49PM +0200, Guillaume Poirier wrote:
>>> I noticed that the include of math.h in libavutil/mathematics.h  
>>> doesn't
>>> seem to be usefull.
>>
>> The point is that it can provide M_E etc. If you remove it and some  
>> code
>> (possibly indirectly) includes <math.h> after mathematics.h those  
>> will
>> be defined twice. I.e. removing it IMHO makes a mess.
>
> Yes, the #include stays.
>
>>> In file included from /usr/include/math.h:26,
>>>               from ./libavutil/mathematics.h:25,
>>>               from ./libavutil/avutil.h:57,
>>>               from liba52/parse.c:40:
>>> /usr/include/architecture/ppc/math.h:179: error: parse error before
>>> '__attribute__'
>>
>> Well, wtf is in math.h that it stumbles over?
>
> This is getting better and better.  First macosx can't link with its
> own libs, and now it can't even compile its own headers.  If this
> keeps up, it won't be long before it stops booting at all, and we'll
> finally see an end to these problems.

It uses __attribute__((always_inline)), and mplayer's liba52/ 
bitstream.h defines  always_inline to __attribute__((always_inline))  
inline, so it's expanded to  
__attribute__((__attribute__((always_inline)) inline)) and pukes.

Attached mplayer patch should fix the root of the problem. (untested)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: always_inline.diff
Type: application/octet-stream
Size: 2464 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080825/59326f81/attachment.obj>
-------------- next part --------------