| Message ID | 20170326185359.5182-3-u@pkh.me |
|---|---|
| State | Accepted |
| Commit | 4ea8f57548f36b0104bc372b2a6d3d4eaae0ce70 |
| Headers | show |
Hi, On Sun, Mar 26, 2017 at 2:53 PM, Clément Bœsch <u@pkh.me> wrote: > This conflict with the DJGPP libc which includes a pow2 function¹ > > We can not make DJGPP posix only to avoid the conflict due to the lack > of posix_memalign. > > [1]: http://www.delorie.com/djgpp/doc/libc-2.02/libc_536.html > --- > libavfilter/vf_psnr.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > Patch is OK. I have no idea what the second line (body) of the commit message means. Ronald
On Sun, Mar 26, 2017 at 05:21:23PM -0400, Ronald S. Bultje wrote: > Hi, > > On Sun, Mar 26, 2017 at 2:53 PM, Clément Bœsch <u@pkh.me> wrote: > > > This conflict with the DJGPP libc which includes a pow2 function¹ > > > > We can not make DJGPP posix only to avoid the conflict due to the lack > > of posix_memalign. > > > > [1]: http://www.delorie.com/djgpp/doc/libc-2.02/libc_536.html > > --- > > libavfilter/vf_psnr.c | 8 ++++---- > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > Patch is OK. I have no idea what the second line (body) of the commit > message means. > I'll improve the message, but basically the djgpp libc can be configured to be POSIX only, where these functions functions and macro (pow2, PI) are not defined. We could do that in the configure (-D_POSIX_SOURCE). Unfortunately, DJGPP does not have posix_memalign(), and will lack its own memalign function we use in lavu/mem.c if we use -D_POSIX_SOURCE. (we could use the recently defunct memalign hack, but better use the proper allocation function).
Hi, On Sun, Mar 26, 2017 at 5:35 PM, Clément Bœsch <u@pkh.me> wrote: > On Sun, Mar 26, 2017 at 05:21:23PM -0400, Ronald S. Bultje wrote: > > Hi, > > > > On Sun, Mar 26, 2017 at 2:53 PM, Clément Bœsch <u@pkh.me> wrote: > > > > > This conflict with the DJGPP libc which includes a pow2 function¹ > > > > > > We can not make DJGPP posix only to avoid the conflict due to the lack > > > of posix_memalign. > > > > > > [1]: http://www.delorie.com/djgpp/doc/libc-2.02/libc_536.html > > > --- > > > libavfilter/vf_psnr.c | 8 ++++---- > > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > > > > Patch is OK. I have no idea what the second line (body) of the commit > > message means. > > > > I'll improve the message, but basically the djgpp libc can be configured > to be POSIX only, where these functions functions and macro (pow2, PI) are > not defined. We could do that in the configure (-D_POSIX_SOURCE). > > Unfortunately, DJGPP does not have posix_memalign(), and will lack its own > memalign function we use in lavu/mem.c if we use -D_POSIX_SOURCE. (we > could use the recently defunct memalign hack, but better use the proper > allocation function). I'm not sure I understand. The user might have installed djgpp instead of libc. But we have no influence whatsoever over how the user compiled djgpp, so FFmpeg should work with as well as without a posix-compiled djgpp, right? Ronald
On Sun, Mar 26, 2017 at 06:17:57PM -0400, Ronald S. Bultje wrote: [...] > > I'll improve the message, but basically the djgpp libc can be configured > > to be POSIX only, where these functions functions and macro (pow2, PI) are > > not defined. We could do that in the configure (-D_POSIX_SOURCE). > > > > Unfortunately, DJGPP does not have posix_memalign(), and will lack its own > > memalign function we use in lavu/mem.c if we use -D_POSIX_SOURCE. (we > > could use the recently defunct memalign hack, but better use the proper > > allocation function). > > > I'm not sure I understand. The user might have installed djgpp instead of > libc. But we have no influence whatsoever over how the user compiled djgpp, > so FFmpeg should work with as well as without a posix-compiled djgpp, right? > pow2() and memalign() prototypes and macros like PI are exposed conditionally in their respective headers. So if you have _POSIX_SOURCE defined in your code and include math.h or stdlib.h, you will not see these symbols (even though they are present in the djgpp libc).
Hi, On Sun, Mar 26, 2017 at 6:39 PM, Clément Bœsch <u@pkh.me> wrote: > On Sun, Mar 26, 2017 at 06:17:57PM -0400, Ronald S. Bultje wrote: > [...] > > > I'll improve the message, but basically the djgpp libc can be > configured > > > to be POSIX only, where these functions functions and macro (pow2, PI) > are > > > not defined. We could do that in the configure (-D_POSIX_SOURCE). > > > > > > Unfortunately, DJGPP does not have posix_memalign(), and will lack its > own > > > memalign function we use in lavu/mem.c if we use -D_POSIX_SOURCE. (we > > > could use the recently defunct memalign hack, but better use the proper > > > allocation function). > > > > > > I'm not sure I understand. The user might have installed djgpp instead of > > libc. But we have no influence whatsoever over how the user compiled > djgpp, > > so FFmpeg should work with as well as without a posix-compiled djgpp, > right? > > > > pow2() and memalign() prototypes and macros like PI are exposed > conditionally in their respective headers. So if you have _POSIX_SOURCE > defined in your code and include math.h or stdlib.h, you will not see > these symbols (even though they are present in the djgpp libc). Oh I understand now, right. The difference between djgpp being posix or us defining _posic_source was throwing me off... Ronald
diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c index af9397123b..1201b2cd7c 100644 --- a/libavfilter/vf_psnr.c +++ b/libavfilter/vf_psnr.c @@ -70,14 +70,14 @@ static const AVOption psnr_options[] = { AVFILTER_DEFINE_CLASS(psnr); -static inline unsigned pow2(unsigned base) +static inline unsigned pow_2(unsigned base) { return base*base; } static inline double get_psnr(double mse, uint64_t nb_frames, int max) { - return 10.0 * log10(pow2(max) / (mse / nb_frames)); + return 10.0 * log10(pow_2(max) / (mse / nb_frames)); } static uint64_t sse_line_8bit(const uint8_t *main_line, const uint8_t *ref_line, int outw) @@ -86,7 +86,7 @@ static uint64_t sse_line_8bit(const uint8_t *main_line, const uint8_t *ref_line unsigned m2 = 0; for (j = 0; j < outw; j++) - m2 += pow2(main_line[j] - ref_line[j]); + m2 += pow_2(main_line[j] - ref_line[j]); return m2; } @@ -99,7 +99,7 @@ static uint64_t sse_line_16bit(const uint8_t *_main_line, const uint8_t *_ref_li const uint16_t *ref_line = (const uint16_t *) _ref_line; for (j = 0; j < outw; j++) - m2 += pow2(main_line[j] - ref_line[j]); + m2 += pow_2(main_line[j] - ref_line[j]); return m2; }