[FFmpeg-devel] [PATCH 2/4] Define __EXTENSIONS__ to enable struct ip_mreq access on OpenSolaris.

[Diego Biurrun]

On Mon, Jan 05, 2009 at 02:47:57PM -0800, Roman V. Shaposhnik wrote:
> On Mon, 2009-01-05 at 22:34 +0100, Diego Biurrun wrote:
> > On Mon, Sep 29, 2008 at 05:27:09PM -0700, Roman Shaposhnik wrote:
> > > On Sun, 2008-09-28 at 23:01 +0200, Diego 'Flameeyes' Petten? wrote:
> > > > "Roman V. Shaposhnik" <rvs at sun.com> writes:
> > > > 
> > > > > You shouldn't really tinker with __* stuff directly. IIRC, there's
> > > > > a more standard way of enabling ip_mreq (something along the lines
> > > > > of defining a proper combination of XPG* and POSIX version). I'd
> > > > > be very surprised if __EXTENSIONS__ were the only way to get what
> > > > > you want.
> > > > 
> > > > struct ip_mreq definition is protected by
> > > > 
> > > > #if !defined(_XPG4_2) || defined(__EXTENSIONS__)
> > > 
> > > This is weird. :-(
> > > 
> > > > Since FFmpeg builds with C99 and requires explicitly POSIX.1-2001
> > > > (-D_POSIX_C_SOURCE=200112L), as soon as _XOPEN_SOURCE is defined,
> > > > _XPG4_2 is also enabled; since there are a few cases where _XOPEN_SOURCE
> > > > is used, and it might well be that more will be introduced, it seems to
> > > > me the most solid option, to define __EXTENSIONS__, rather than relying
> > > > on _XOPEN_SOURCE *not* being defined.
> > > > 
> > > > Of course if you have a better idea...
> > > 
> > > Let me look at it and talk to our POSIX/XPG "standard lawyers". It 
> > > appears that defining __EXTENSIONS__ is, indeed, the only option.
> > > But I still suspect that shouldn't be the case.
> > 
> > Roman, any results?
> 
> Some. On one hand, defining __EXTENSIONS__
> is entirely legitimate way for asking 
> features that are outside of most 
> standards(5):
>    http://docs.sun.com/app/docs/doc/819-2252/standards-5?a=view
> ----------------------------------------------
> If the application is using interfaces and 
> headers not defined by that standard, then 
> in addition to defining the appropriate 
> standard feature test macro, it must also 
> define __EXTENSIONS__. Defining __EXTENSIONS__
> provides the application with access to all
> interfaces and headers not in conflict with 
> the specified standard. The application must 
> define __EXTENSIONS__ either on the compile 
> command line or within the application source 
> files.
> ----------------------------------------------
> 
> On the other hand, I still feel that it is
> too big of a hammer to be used at the level
> of -D__EXTENSIONS__
> 
> If I had my vote -- I'd rather carefully placed
>    #define __EXTENSIONS__ 1 
> in files where they are really called for.

Well, flameeyes sent a patch to do this, if you prefer his solution,
revert my change and apply his patch or something similar instead.

Diego