Re: [xine-devel] Re: [xine-cvs] CVS: xine-lib/src/libffmpeg/libavcodec wmadec.c,1.9,1.10

[Miguel F. <mi...@ce...>]

Hi James,

On Tue, 2004-05-11 at 19:21, James Stembridge wrote:
> I think the real problem here is the configure check for lrintf, as it defines 
> _ISOC9X_SOURCE. If this finds lrintf then HAGVE_LRINTF is defined and the one 
> provided in libavcodec/dsputil.h isn't used. However when it comes to compile 
> wmadec.c _ISOC9X_SOURCE isn't defined and so lrintf isn't really available.


yes, i know that. i haven't just guessed the fix ;-)

the funny thing is libfaad does something similar, it forces several
#defines to make sure lrintf will be available.


> The strange thing here is if I remove the _ISOC9X_SOURCE from the configure 
> check, then the check for lrintf fails. However when I compile libavcodec I 
> get errors like:
> 
> ../dsputil.h:562: warning: static declaration for `lrintf' follows non-static
> 
> Which implies that it is getting defined somewhere else though I can't figure 
> out where.

the glibc mechanism for declaring lrintf is still somewhat confuse to
me. i noticed that, in my system, lrintf prototype is only available as
an inlined function that only gets included when certain optimizations
are enabled. people reported similar problems here:

http://gcc.gnu.org/ml/gcc/2001-10/msg01104.html

yes, we could add -D_GNU_SOURCE to ffmpeg cflags. that is a reasonable
solution for libffmpeg but not for other xine modules that might want to
use lrintf.

what do you think of always defining _ISOC9X_SOURCE (in config.h) if
HAVE_LRINTF is defined? at least this should make sure our configure
check is not lying about the function availability...

regards,

Miguel