[Ffmpeg-devel] libavutil conflict with system headers on Darwin

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> Hi
>
> On Sat, Dec 02, 2006 at 09:03:20PM +0100, Diego Biurrun wrote:
>> On Tue, Nov 28, 2006 at 05:58:11PM +0000, M?ns Rullg?rd wrote:
>> > Diego Biurrun <diego at biurrun.de> writes:
>> > 
>> > > On Sat, Nov 25, 2006 at 05:42:58PM -0500, Alexander Strange wrote:
>> > >> This no longer compiles:
>> > >> #include <libavutil/common.h>
>> > >> #include <math.h>
>> > >> 
>> > >> because of:
>> > >> #ifndef always_inline
>> > >> #if defined(__GNUC__) && (__GNUC__ > 3 || __GNUC__ == 3 && __GNUC_MINOR__ > 0)
>> > >> #    define always_inline __attribute__((always_inline)) inline
>> > >> #else
>> > >> #    define always_inline inline
>> > >> #endif
>> > >> #endif
>> > >> 
>> > >> on common.h:55.
>> > >> 
>> > >> On Darwin, some headers use __attribute__((always_inline)) on their  
>> > >> own, which the above macro then mangles.
>> > >> (__GNUC__ is defined as 4 on all darwin/x86 systems and almost all  
>> > >> ppc systems)
>> > >
>> > > Any ideas how to fix this (cleanly)?  Just add something like ifndef
>> > > Darwin to the above declaration?
>> > 
>> > That's not what I call clean.  Renaming our version to
>> > ff_always_inline or something would be better.
>> 
>> So is renaming always_inline to ff_always_inline acceptable?  If I don't
>> hear objections I will implement this after the weekend.
>
> does renaming the code in common.h and adding
>
> #ifdef HAVE_AV_CONFIG_H
> #   define always_inline ff_always_inline
> #   define ABS FFABS
> #   define MAX FFMAX
> #endif
>
> help?

No.  It will only make it break differently.

> yes, i do prefer
>
> always_inline foobar(){
>     int vector[4], i;
>     for(i=0; i<4; i++)
>         vector[i]= MAX(ABS(2-i), 1);
> }
>
> over
>
> FF_always_inline foobar(){
>     int FF_vector[4], i;
>     for(i=0; i<4; i++)
>         FF_vector[i]= FFMAX(FFABS(2-i), 1);
> }
>
> or is it rather
>
> FF_always_inline foobar(){
>     int FF_vector[4], FF_i;
>     for(FF_i=0; FF_i<4; FF_i++)
>         FF_vector[FF_i]= FFMAX(FFABS(2-FF_i), 1);
> }
>
> what we are moving toward?

No, local variables can have any names.  Things defined by us that are
visible outside lav* should be named that minimize the risk of
conflicts.  The things in question are symbols with external linkage
and preprocessor macros visible to apps using lav* or are defined
before system headers are included when building ffmpeg.

-- 
M?ns Rullg?rd
mru at inprovide.com