[FFmpeg-devel] redundant ff_inverse symbol

[pin xue]

After?2010-07-21?changes (flameeyes,?Make ff_inverse stay with
libavutil, and optional copy...), inverse.c is redundant in libavutil
and in libavcodec, the contents are identical, indeed the copy in
libavcodec is defined as following:
#include?"libavutil/inverse.c"

Which results both the libavutil.a and libavcodec.a contains symbol
ff_inverse. When trying to create a single .so from all .a, gnu ld
will complains :
(libavutil/libavutil.a)inverse.o
libavutil/libavutil.a(inverse.o):(.rodata+0x0): multiple definition of
`ff_inverse'
libavcodec/libavcodec.a(inverse.o):(.rodata+0x0): first defined here
and fails silently.
Per my observation, there are only two files refer ff_inverse (without
declaration)
:libavcodec$ grep ff_inverse *.c
msmpeg4.c: ? ? ? ?: "g" (scale), "S" (ff_inverse[scale])
vorbis_dec.c: ? ? ? ? ? ? ? ?uint_fast32_t inverse_class =
ff_inverse[vr->classifications];
And six files refer FASTDIV:
dca.c: ? ? ? ?int div = FASTDIV(code, levels);
flacenc.c: ? ?k ? ?= av_log2(n < 256 ? FASTDIV(sum2, n) : sum2 / n);
mpeg4video.h: ? ?pred = FASTDIV((pred + (scale >> 1)), scale);
mpeg4videodec.c: ? ? ? ? ? ?if(n<4) level= FASTDIV((level +
(s->y_dc_scale>>1)), s->y_dc_scale);
mpeg4videodec.c: ? ? ? ? ? ?else ? ?level= FASTDIV((level +
(s->c_dc_scale>>1)), s->c_dc_scale);
msmpeg4.c: ? ?return FASTDIV((sum + (scale>>1)), scale);
msmpeg4.c: ? ? ? ?a = FASTDIV((a + (scale >> 1)), scale);
msmpeg4.c: ? ? ? ?b = FASTDIV((b + (scale >> 1)), scale);
msmpeg4.c: ? ? ? ?c = FASTDIV((c + (scale >> 1)), scale);
vorbis_dec.c:
: FASTDIV(vr->partition_size, dim);
And Makefile mentioned:
614 # inverse.o contains the ff_inverse table definition, which is used by
615 # the FASTDIV macro (from libavutil); since referencing the external
616 # table has a negative effect on performance, copy it in libavcodec as
617 # well.
618 OBJS-$(!CONFIG_SMALL) ? ? ? ? ? ? ? ? ?+= inverse.o
In theory, symbol reference can be solved in link&load stage, once
done it should just be a in-process memory access, I'm not very sure
about the performance impacts mentioned, but keep the possibility to
combine all these .a into one .so is really nice.

--
Best Regards!

Yang Wu
--------------------------------------------------------
Location: Pudong, Shanghai, China.
EMail? ? : pinxue at gmail.com
RockPlayer Website: http://www.anplayer.com
Personal Website: http://www.pinxue.net