[MPlayer-cvslog] r27240 - trunk/configure

[Michael Niedermayer]

On Mon, Jul 14, 2008 at 09:58:58PM +0200, Michael Niedermayer wrote:
> On Mon, Jul 14, 2008 at 10:45:58AM +0200, Diego Biurrun wrote:
> > On Mon, Jul 14, 2008 at 02:36:59AM +0200, Michael Niedermayer wrote:
> > > On Sun, Jul 13, 2008 at 12:54:37PM +0200, Reimar Döffinger wrote:
> > > > On Sun, Jul 13, 2008 at 12:49:16PM +0200, Diego Biurrun wrote:
> > > > > > Could you please post a few of the warnings you where trying to fix. There
> > > > > > may be a more correct and clean way to get rid of them.
> > > > > 
> > > > > Warnings like the following, there was a handful of them:
> > > > > 
> > > > > libmpcodecs/ad_libvorbis.c: In function 'read_vorbis_comment':
> > > > > libmpcodecs/ad_libvorbis.c:48: warning: implicit declaration of function 'vsscanf'
> > > > 
> > > > Well, at least my man page suggests these solutions to that:
> > > > "_XOPEN_SOURCE >= 600 || _ISOC99_SOURCE; or cc -std=c99"
> > > > at least strictly speaking, -std=gnu99 is not among the recommended
> > > > solutions.
> > > 
> > > Ohh lord, this must have been written before the birth of the saviour uoti.
> > > 
> > > > In addition, -D_ISOC99_SOURCE would work in all compilers,
> > > > not just gcc (though ICC probably supports it anyway and no other
> > > > compiler is supported. Still...).
> > > 
> > > Heretic, dont you know that all compilers must use the --std=gnu99 switch
> > > to enable ISO C99 mode, how can you dare to even mention a standard
> > > compliant solution. --std=gnu99 must be used the saviour has decided
> > > and he knows what is best.
> > > Dont be blinded by the mention of these defines in the POSIX spec, they
> > > have been placed by the devil there to confuse you. --std=gnu99 is the
> > > only and best way to compile C99 programs!
> > 
> > Stop flaming already.
> 
> And accept the lies of uoti and your lack of any clue about the subject?
> 
> As an example of one of uotis lies, try
> --std=c99 -fasm it will compile asm() just fine.
> 
> 
> > 
> > -std=gnu99 is closer to C99 than -std=gnu89, period.  
> 
> That may be true but we did NOT explicitly use -std=gnu89
> 
> 
> > This change
> > already helped find and fix some non-C99 constructs in FFmpeg.  If you
> > want to see -std=c99 used, then make FFmpeg compilable with that flag,
> > which is a prerequisite for MPlayer to use it.
> 
> I did not suggest --std=c99 to be used. I just said that there are many
> solutions and --std=gnu99 is the worst. And not what we want at all ...
> Of course that does not mean that --std=c99 should not be considered, just
> that these 2 are not the only options.
> 
> 
> What iam saying all along is that the standard way to enable various C99 
> prototypes in the headers is
> -D_ISOC99_SOURCE or -D_XOPEN_SOURCE=600 or _POSIX_C_SOURCE
> 
> These are documented for that purpose in the man pages as shown by reimar
> and you can look at the official POSIX standard for example at
> www.opengroup.org. It as well mentions these defines.

Let me quote it
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html

"A POSIX-conforming application should ensure that the feature test macro _POSIX_C_SOURCE is defined before inclusion of any header."

"An XSI-conforming application should ensure that the feature test macro _XOPEN_SOURCE is defined with the value 600 before inclusion of any header. This is needed to enable the functionality described in The _POSIX_C_SOURCE Feature Test Macro and in addition to enable the XSI extension."


info libc:
 -- Macro: _ISOC99_SOURCE
     Until the revised ISO C standard is widely adopted the new features
     are not automatically enabled.  The GNU libc nevertheless has a
     complete implementation of the new standard and to enable the new
     features the macro `_ISOC99_SOURCE' should be defined.

 -- Macro: _GNU_SOURCE
     If you define this macro, everything is included: ISO C89,
     ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU
     extensions.  In the cases where POSIX.1 conflicts with BSD, the
     POSIX definitions take precedence.

     If you want to get the full effect of `_GNU_SOURCE' but make the
     BSD definitions take precedence over the POSIX definitions, use
     this sequence of definitions:

          #define _GNU_SOURCE
          #define _BSD_SOURCE
          #define _SVID_SOURCE

     Note that if you do this, you must link your program with the BSD
     compatibility library by passing the `-lbsd-compat' option to the
     compiler or linker.  *Note_* If you forget to do this, you may get
     very strange errors at run time.
-------------------
Do we want all that _GNU_SOURCE enables ?
Do we want mplayer to require and depend on all that _GNU_SOURCE enables ?
no?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I count him braver who overcomes his desires than him who conquers his
enemies for the hardest victory is over self. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/attachments/20080714/bbcbc25b/attachment.pgp>