[FFmpeg-devel] [PATCH] fix compilation in cygwin

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Tue, Jan 12, 2010 at 09:28:37AM -0500, Vitor Sessak wrote:
>> M?ns Rullg?rd wrote:
>>> Vitor Sessak <vitor1001 at gmail.com> writes:
>>>> M?ns Rullg?rd wrote:
>>>>> Vitor Sessak <vitor1001 at gmail.com> writes:
>>>>>
>>>>>> M?ns Rullg?rd wrote:
>>>>>>> Michael Kostylev <michael.kostylev at gmail.com> writes:
>>>>>>>
>>>>>>>> On Sun Jan 10 21:55:50 2010
>>>>>>>> Vitor Sessak wrote:
>>>>>>>>
>>>>>>>>>>> +#if !HAVE_EXP2F
>>>>>>>>>>> +static av_always_inline av_const float exp2f(float x)
>>>>>>>>>>> +{
>>>>>>>>>>> +    return exp(x) * 0.693147180559945;
>>>>>>>>>>> +}
>>>>>>>>>>> +#endif /* HAVE_EXP2F */
>>>>>>>>>> Same again.  exp2() should be preferred.
>>>>>>>>> Let's hope that at least exp2() is supported...
>>>>>>>> exp2() is missing in NetBSD and DragonFly.
>>>>>>> We have a replacement for it, so it's OK.
>>>>>> We have a replacement for log2(), but not for exp2().
>>>>>>
>>>>>> I'm slightly favorable of adding a replacement for exp2() (as
>>>>>> attached) as we do for log2(), since we can get some speed gain in
>>>>>> platforms where exp2() is supported and we'll eventually need exp2()
>>>>>> sooner or later.
>>>>>>
>>>>>> [...]
>>>>> Well, this caused things to break in new and interesting ways:
>>>>> libavutil/internal.h:275: error: static declaration of 'exp2f'
>>>>> follows non-static declaration
>>>>> libavutil/internal.h:296: error: static declaration of 'log2f' follows 
>>>>> non-static declaration
>>>>> uClibc apparently has declarations for those functions, but no actual
>>>>> implementations.  This is truly the week of idiots.
>>>> BTW, wouldn't compilation fail if log2f() is a macro?
>>> No.  The functions are required to be available as actual functions,
>>> even if a macro is also defined.
>>
>> What about if we define them as macros? Should work on any case.
>
> First let us make sure the macro+function issue is real, has whoever
> reported this made sure he has the correct headers and matching
> libs?

The problem is that the headers and "matching" libs don't agree.

> that he has #defined all the POSIX whatever stuff & greped the
> manual linked to libm ...

These are standard C functions.

-- 
M?ns Rullg?rd
mans at mansr.com